Localize Core Messages

[GLWine]

Description:

This PR implements localization for core application messages in EDMarketConnector.py, enabling translation of critical user-facing strings such as error popups, notifications, and startup warnings. The changes standardize message formatting and consolidate i18n handling across the application.

This work is a parallel integration to PR #2617, which localized the authentication success message. Together, these changes expand localization coverage to additional core UI elements while maintaining consistency with the established patterns.

Key Changes:

• Import Optimization: Moved l10n import earlier and removed duplicate imports to ensure translations are available throughout the file.
• String Localization: Replaced hard-coded strings in popups, notifications, and dialogs with tr.tl() calls for proper translation support.
• Newline Standardization: Introduced {LF}{CR} placeholders in localization strings to handle line breaks consistently, replacing manual replace('\\n','\n').replace('\\r','\r') post-processing.
• New Localization Entries: Added translations for startup messages including journal lock warnings and duplicate process detection.
• Updated Templates: Modified en.template to include new entries and standardize existing ones with newline placeholders.

Files Modified:

• EDMarketConnector.py: 58 lines changed (+34/-24) - Added translation calls and removed manual formatting.
• en.template: 18 lines changed (+12/-6) - Added new strings and updated formatting.

Benefits:

• Improves user experience for non-English speakers by localizing core error and status messages.
• Centralizes message handling, making future translations easier.
• Ensures consistent formatting across all localized messages.

This PR targets the develop branch and maintains backward compatibility while enhancing internationalization support. All changes are based on the existing l10n infrastructure and follow the project's translation patterns established in PR #2617.

Attention: @Rixxan

[Rixxan]

I'm wary about the newline conversion to {LF}{CR}{LF}{CR}. How will this impact bundled languages? Will updates need to be made to every language or risk crashes? (While in theory I'm not against standardizing newlines, it's one of those "the way it's always been" things that I'm worried might introduce unintended consequences.

[GLWine]

Hey @Rixxan, thanks for the feedback! Your concern was valid, here's the full picture:

How placeholders are handled

• I removed the inline .format() calls only for {CR}: {CR} is already handled by l10n.py
• {EOL} is handled with .format() where it is used
  • We could make l10n.py always handle the substitution, but for now it's done inline where {EOL} appears

Behavior with existing translations

• Translations that are not yet updated fall back to the untranslated string
• No crashes, just fallback until the translation is refreshed

Impact on Crowdin

• Strings that previously used \n or \r\n now use {CR} and {EOL}
• Crowdin sees them as new strings and they need to be re-synced
• The translations already exist, they just need to be updated with the new placeholder

Conclusion

• The impact is limited to the affected strings
• Fallback is in place until translations are updated on Crowdin

---

TODO (next step)

In a follow-up (either in this PR or a new one), we can move the {EOL} substitution into l10n.py itself, just like {CR}. This would be done in two places:

1. contents() — when loading translations from .strings files:

   to_set = match.group(2).replace(r'\"', '"').replace('{CR}', '\n').replace('{EOL}', '\r\n')

2. translate() — in the fallback path when the string is missing:

   return self.translations[None].get(x) or str(x).replace(r'\"', '"').replace('{CR}', '\n').replace('{EOL}', '\r\n')

This would let us remove all inline .format() calls for {EOL} and centralize the logic in one place, making the codebase cleaner and more consistent.