gandalf suggested https://github.com/projectfluent/fluent/issues/80 could help in this case already having a localized fluent string for ``` source-name-edge = Microsoft Edge ``` https://searchfox.org/mozilla-central/rev/5a4aaccb28665807a6fd49cf48367d47fbb5a19a/browser/locales/en-US/browser/migration.ftl#83 to reuse as an arg within another fluent string. Although sounds like there's some uncertainty of that approach. Alternatively for more immediate implementation and I believe more in line with Gijs' patch https://phabricator.services.mozilla.com/D80944 - it's always clear for localizers what browser names are available - localizers can do proper grammar around the names of browsers as would be appropriate in their language. Another alternative is to combine the async localization pass getting the localized source-browser name with the async process of detecting importable logins, but this has potential downsides of passing around previously localized strings that don't get updated when the desired locale changes. But this would match the existing behavior with no changes to the existing string: https://searchfox.org/mozilla-central/rev/5a4aaccb28665807a6fd49cf48367d47fbb5a19a/toolkit/locales/en-US/toolkit/main-window/autocomplete.ftl#8-12 ``` autocomplete-import-logins = <div data-l10n-name="line1">Import your login from { $browser }</div> <div data-l10n-name="line2">for { $host } and other sites</div> ``` flod, is there any preference to how we should expose the string for localization?
Bug 1649180 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
gandalf suggested https://github.com/projectfluent/fluent/issues/80 could help in this case already having a localized fluent string for ``` source-name-edge = Microsoft Edge ``` https://searchfox.org/mozilla-central/rev/5a4aaccb28665807a6fd49cf48367d47fbb5a19a/browser/locales/en-US/browser/migration.ftl#83 to reuse as an arg within another fluent string. Although sounds like there's some uncertainty of that approach. Alternatively for more immediate implementation and I believe more in line with Gijs' patch https://phabricator.services.mozilla.com/D80944 of exposing per-browser copies of the string: - it's always clear for localizers what browser names are available - localizers can do proper grammar around the names of browsers as would be appropriate in their language. Another alternative is to combine the async localization pass getting the localized source-browser name with the async process of detecting importable logins, but this has potential downsides of passing around previously localized strings that don't get updated when the desired locale changes. But this would match the existing behavior with no changes to the existing string: https://searchfox.org/mozilla-central/rev/5a4aaccb28665807a6fd49cf48367d47fbb5a19a/toolkit/locales/en-US/toolkit/main-window/autocomplete.ftl#8-12 ``` autocomplete-import-logins = <div data-l10n-name="line1">Import your login from { $browser }</div> <div data-l10n-name="line2">for { $host } and other sites</div> ``` flod, is there any preference to how we should expose the string for localization?
gandalf suggested https://github.com/projectfluent/fluent/issues/80 could help in this case already having a localized fluent string for ``` source-name-edge = Microsoft Edge ``` https://searchfox.org/mozilla-central/rev/5a4aaccb28665807a6fd49cf48367d47fbb5a19a/browser/locales/en-US/browser/migration.ftl#83 to reuse as an arg within another fluent string. Although sounds like there's some uncertainty of that approach. --- Alternatively for more immediate implementation and I believe more in line with Gijs' patch https://phabricator.services.mozilla.com/D80944 of exposing per-browser copies of the string: - it's always clear for localizers what browser names are available - localizers can do proper grammar around the names of browsers as would be appropriate in their language. ``` autocomplete-import-logins-edge = <div data-l10n-name="line1">Import your login from Microsoft Edge</div> <div data-l10n-name="line2">for { $host } and other sites</div> ``` --- Another alternative is to combine the async localization pass getting the localized source-browser name with the async process of detecting importable logins, but this has potential downsides of passing around previously localized strings that don't get updated when the desired locale changes. But this would match the existing behavior with no changes to the existing string: https://searchfox.org/mozilla-central/rev/5a4aaccb28665807a6fd49cf48367d47fbb5a19a/toolkit/locales/en-US/toolkit/main-window/autocomplete.ftl#8-12 ``` autocomplete-import-logins = <div data-l10n-name="line1">Import your login from { $browser }</div> <div data-l10n-name="line2">for { $host } and other sites</div> ``` flod, is there any preference to how we should expose the string for localization?