New Firefox strings exposed on pontoon

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

New Firefox strings exposed on pontoon

Axel Hecht
Hi,

I'm happy to let you know that we're exposing new strings on pontoon for
Firefox again. I can only apologize for the delay.

A couple of comments on the new strings, adjust the links to your locale
[1].

We added our first fluent file in Firefox,
https://pontoon.mozilla.org/de/firefox/browser/browser/preferences/main.ftl/.
[2].

In
https://pontoon.mozilla.org/de/firefox/browser/chrome/browser/browser.dtd/?search=newTabControlled.header.message,
"New Tab" should be translated consistently with the title of a new tab,
https://pontoon.mozilla.org/de/firefox/browser/chrome/browser/newTab.dtd/?search=newtab.pageTitle.

https://pontoon.mozilla.org/de/firefox-for-android/mobile/android/base/android_strings.dtd/?search=pref_custom_tabs_summary4 
lost its period.

Flod also clarified the length-limit comments in
security/manager/chrome/pipnss/pipnss.properties. Please make sure to
stick to them, or leave the strings in English. We can't modify the
length, as that's part of a standardized message protocol between
Firefox and security devices. That's also why it's utf-8 bytes, and not
characters.

suite/chrome/common/about.dtd is a copy of
toolkit/chrome/global/about.dtd. If you're working on suite, just use hg
to copy that over. Or ask for help. about: is getting removed in
Firefox, but is a needed part on SeaMonkey, that's why it's copied over
there.

In case you're working on mercurial, please don't touch
browser/firefox-l10n.js, mail/all-l10n.js, mobile/android/mobile-l10n.js
yet. We (aka flod) will help with that once we stop shipping Firefox 58.

That's the comments. If you're curious to stick around for the
background of the delays, feel free, otherwise you can stop reading now.

There's been a series of delays that I'd like to apologize for. First
off, we still have merge days of our en-US code, and we have multiple
ways to do that in hg. Effectively, we have hundreds of changesets
showing up on Beta and Release. Changesets that we've already dealt
with, but then also, now we're dealing with them in a different context,
as the set of revisions that go into the current state changed.
Supporting that has been trickier than I thought, and I had to tweak a
bit of existing code to not do anything on merge days, and add code to
do something on merge day.

What we ended up doing is to have a single commit for merge days, mapped
to the tip of the push of the merge, that updates all files that changed
between the old and the new beta or release state. That's the commit
that will end up removing all the strings that are not used in any
shipping version of Firefox anymore.

Getting to that state took me a couple of failed attempts, thanks to
flod for talking me through all of those and finalizing on the final
version.

Once I made it over that hump, quite a bit of changes had accrued. Those
had two more version-control patterns that triggered bugs in the
existing code, which took a couple of days each to figure out.

And then we had to actually review the strings that came in in the
meantime before pushing them out to you.

Done now, merry localizing, and sorry again

Axel



[1] Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1424845 on
getting support for language agnostic links.
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1424852, fixed and
deployed.
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n