Closed Bug 1649180 Opened 4 years ago Closed 4 years ago

Localize password import source-browser name

Categories

(Toolkit :: Password Manager, enhancement, P1)

enhancement

Tracking

()

RESOLVED FIXED
81 Branch
Iteration:
81.1 - July 27 - Aug 09
Tracking Status
firefox81 --- fixed

People

(Reporter: Mardak, Assigned: Mardak)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

If we decide to turn on the feature with bug 1648182, we'll need to figure out how we want to expose the "Import your login from Google Chrome / for bugzilla.mozilla.org and other sites" message. (We might end up changing the message too depending on final product/ux designs.)

Bug 1648171 patch from Gijs suggested exposing a version of the string for each potential source browser with https://phabricator.services.mozilla.com/D80944

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?

Flags: needinfo?(francesco.lodolo)
  1. Gijs solution is going to provide sound translations, because localizers have context and control over the entire sentence.
  2. The last alternative (what we have), is OK-ish: we don't expose the name of the other browsers, so locales need to treat them as foreign words on which they have no control.

I'm not a fan of the solution suggested in the dynamic reference conversation: if we expose those brand names, they should be terms with private attributes, not normal messages. And then you need to figure out how to deal with that in the syntax.

On paper it seems better than 2, but it's not, because it only solves part of the problem. At that point, #2 is better with all its limitation.

So, I'd go with #1 (Gijs solution) over #2.

Flags: needinfo?(francesco.lodolo)
Severity: -- → N/A
Blocks: 1651233
Assignee: nobody → edilee
Iteration: --- → 80.2 - July 13 - July 26
Priority: P3 → P1

Based on the approach in D80944 but of the supported browser ids.

Iteration: 80.2 - July 13 - July 26 → 81.1 - July 27 - Aug 09
Pushed by elee@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fb86d921926d
Localize password import source-browser name r=MattN,fluent-reviewers,flod
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: