+++ This bug was initially created as a clone of Bug #1244670 +++ Hey Folks, it seems you haven't fixed some of the strings for productization, the following are missing: mail.addr_book.mapit_url.1.format mail.addr_book.mapit_url.1.name mail.addr_book.mapit_url.2.format mail.addr_book.mapit_url.2.name Can you make sure to fix this until Thunderbird 45 is released? This bascially means in the next ~20 days since we need time to build the releases.
We're now localizing via Pootle and I don't see these strings there.
@Philipp region.properties is excluded on purpose from Pootle and Pontoon, since we don't want unreviewed changes to land. Also, most of the teams working on such tools don't have Mercurial commit access. You'll need to land these changes in the l10n repositories, or modify the code so that it fallbacks to English values if the keys are missing.
@flod: Thanks for the update, I suspected as much. compare-locales -m should be merging these strings, so it is nothing blocking the release, but of course it would be nice to get them translated. How are region changes usually managed for Firefox? I can of course land the changes, but for that I need the strings translated. @Kevin: Can you translate the strings and post them here? http://mxr.mozilla.org/comm-beta/source/mail/locales/en-US/chrome/messenger-region/region.properties
(In reply to Philipp Kewisch [:Fallen] from comment #3) > @flod: > Thanks for the update, I suspected as much. compare-locales -m should be > merging these strings, so it is nothing blocking the release, but of course > it would be nice to get them translated. How are region changes usually > managed for Firefox? I can of course land the changes, but for that I need > the strings translated. There are things in region.properties that you really don't want to merge (think for example of search.order), so compare-locales is not a viable option. Luckily we didn't have any of these changes in Desktop. We had one in mobile, but those keys are ignored by filter.py (not reported if missing), and the code fall backs to en-US if they're not available. http://hg.mozilla.org/mozilla-central/file/tip/mobile/locales/filter.py#l42 If changes to region.properties are needed, I usually send an email to dev-l10n to whitelist them, then file a bug to track the changes and start fixing them myself. See for example bug 994248 and https://l10n.mozilla-community.org/~flod/p12n/bug994248_ssl/ In this case I'm not completely sure you need a translation for "Google Maps" or "OpenStreetMap". If it helps, I can create a view to track which locales are missing those keys.
The en-US values for all four strings work fine. We don't typically translate trademarked names like Google Maps or OpenStreetMap.
(In reply to Francesco Lodolo [:flod] from comment #4) > If it helps, I can create a view to track which locales are missing those > keys. Scratch that. I'm not storing those values, and I should stop reporting these keys as unknown too in my tools.
Please don't forget to request sign-off for Thunderbird on beta for this to be included. I suspect this will be part of beta 3 unless you have time to request sign-off until tomorrow. But don't worry, it is not a problem to have this in b3.