chore(l10n): extract strings, add docs, load locales on demand#452
chore(l10n): extract strings, add docs, load locales on demand#452
Conversation
|
ba08f2e was deployed to: https://fred-pr452.review.mdn.allizom.net/ |
|
Converted to draft, as it has merge conflicts. |
bcolsson
left a comment
bcolsson
left a comment
There was a problem hiding this comment.
I understand that more work is happening around localization at some point in the future, but I noticed some major issues that could cause headaches down the road, so adding comments. I'd suggest making changes before asking localizers to translate these. (If the expectation is to use Pontoon, then the complicated Fluent logic wouldn't be supported well either.)
| footer-copyright = Portions of this content are ©1998–{ $year } by individual mozilla.org contributors. Content available under <a data-l10n-name="cc">a Creative Commons license</a>. | ||
| search-modal-site-search = Site search for <em>{ $query }</em> | ||
| site-search-search-stats = Found { $results } documents. | ||
| site-search-suggestion-matches = |
There was a problem hiding this comment.
While this is technically valid fluent it's best to avoid this pattern. This should be two strings - otherwise you can't guarantee that all patterns will have translations (reference).
Typically you want to remove the logic from the strings themselves, so it's preferable to have a -greaterthan and a -equals string then have the logic happening outside of fluent to choose the correct string.
| compat-support-flags = | ||
| { NUMBER($has_added) -> | ||
| [one] From version { $version_added } | ||
| *[other] { "" } | ||
| }{ $has_last -> | ||
| [one] | ||
| { NUMBER($has_added) -> | ||
| *[zero] Until { $versionLast } users | ||
| [one] { " " }until { $versionLast } users | ||
| } | ||
| *[zero] | ||
| { NUMBER($has_added) -> | ||
| *[zero] Users | ||
| [one] { " " }users | ||
| } | ||
| } | ||
| { " " }must explicitly set the <code data-l10n-name="name">{ $flag_name }</code>{ " " } | ||
| { $flag_type -> | ||
| *[preference] preference | ||
| [runtime_flag] runtime flag | ||
| }{ NUMBER($has_value) -> | ||
| [one] { " " }to <code data-l10n-name="value">{ $flag_value }</code> | ||
| *[other] { "" } | ||
| }{ "." } | ||
| { $flag_type -> | ||
| [preference] To change preferences in { $browser_name }, visit { $browser_pref_url }. | ||
| *[other] { "" } | ||
| } |
There was a problem hiding this comment.
This is untranslatable. Even in English I barely understand what a final string would look like, so compounding translations with different word order, you'll have a very difficult time to get something comprehensible out of this.
This should be split into multiple strings. E.g.
string-a = From version { version }
string-b = From version { version } until {version} users
ETc.
| compat-experimental = Experimental | ||
| compat-nonstandard = Non-standard | ||
| compat-no = No | ||
| compat-support-full = Full support |
There was a problem hiding this comment.
I'm finding this and multiple other strings with the exact same ID. You'll need to find a way to avoid duplication.
| compat-legend-preview = In development. Supported in a pre-release version. | ||
| compat-legend-no = { compat-support-no } | ||
| compat-legend-unknown = Compatibility unknown | ||
| compat-legend-experimental = { compat-experimental }. Expect behavior to change in the future. |
There was a problem hiding this comment.
I sort of understand why you want to use a reference here and below, but there is the potential for localization issues here. It'd be simpler for localizers to just have the word instead of a message reference.
|
@bcolsson thanks for your comments, once we've got the mechanics of our string scraping sorted out in this PR, we'll open others to resolve what you've noted, and make some of the auto-generated ids more meaningful. @caugner I've updated this PR in line with what we discussed a little while ago in Berlin: removing the ability to add strings without defining an id. I temporarily used some of that logic in the migration script to update the current id-less instances to ones with ids. Commits are mostly atomic - they may not all stand alone, because for some of them I simply split up my previous large commit more logically - but should be much nicer to review than before. |
4 participants
Gets things to a stage where all strings are - in theory - l10n-able. Next steps will be improving the l10n experience, and further optimising which strings we ship to the client.
The added README is a good source for some of what's going on here.