-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[Bug] Ordered vs unordered placeables in strings #7212
Comments
@flodolo You're right, we should definitely switch to this. We can start doing this for all new strings immediately. How should we migrate the existing strings? |
That's a good question. I see a few options, leaving to Delphine/Pike the choice:
The sooner we confirm that locales like Japanese are not breaking, and update en-US strings, the better, considering we have a lot of locales starting from scratch with this project. |
To be really sure, we need to check all call sites, and see if they're using the API, and not manually replacing As for updating localizations, if you want to do that on a repo, it'll need to be a PR on |
From a quick look, I've only found 2 strings in Fenix using multiple default_device_name search_add_custom_engine_search_string_example Mismatches in localesdefault_device_name mozac_lib_crash_dialog_button_restart default_device_name default_device_name |
In Firefox desktop it's possible to switch from unordered to ordered placeables in the localized strings (and the other way around). For example
Click %S to open %S
is equivalent toClick %1$S to open %2$S
.That's handy, and also needed in cases where the locale needs to change the order of parameters compared to en-US.
Now, it looks like some locales are doing the same thing in Fenix. Example, this string
In Japanese becomes:
Can someone verify in product that this is working? In general, it would be great to always use ordered placeables in the source string when there's more than one, because not every language is aware that you can swap them (assuming that actually works in Android).
cc @Delphine @Pike
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: