Mibbit mass-landing on Tuesday (tomorrow) at 7 AM UTC
Staś Małolepszy
As you may remember, some time ago the support for irc/ircs protocol was
added to Firefox, and Mibbit.com was chosen as a default handler in
en-US. Bug https://bugzilla.mozilla.org/show_bug.cgi?id=479030 was
tracking which locales wanted Mibbit too, and the list as of today is:
ar, ca, cs, da, de, eu, fa, fi, fr, ga-IE, he, hu, is, ja, ja-JP-mac,
lt, nn-NO, pl, pt-BR, ru, sk, sv-SE, te, tr, vi, zh-CN, zh-TW
I'm going to mass-add Mibbit on 1.9.1 branch for these locales tomorrow
morning, somewhere around 9 AM CET / 7 AM UTC / 12 AM (midnight) PDT.
I'm going to update my local clones first of course in order minimize
the risk of merge conflict and then post here again to report when I'm done.
*Please remember to 'hg pull -u' next time you work in your clones.*
(If your locale is not on the list above and you want it to be added to
it and you haven't added Mibbit yet yourself, now is the last call to do
this. Please edit the whiteboard in bug 479030 by tomorrow morning. If
you don't do it by this time, no worries. Just file an individual bug in
your locale's component and CC st...@mozilla.com.)
If you have any questions, please don't hesitate to e-mail me directly
at st...@mozilla.com or reply in this thread.
... and wish me luck :)
Best,
Staś
--
Staś Małolepszy
Mozilla L10n driver
+48 600462291
+33 643800452
flod (Francesco Lodolo)
> As you may remember, some time ago the support for irc/ircs protocol
> was added to Firefox, and Mibbit.com was chosen as a default handler
> in en-US. Bug https://bugzilla.mozilla.org/show_bug.cgi?id=479030 was
> tracking which locales wanted Mibbit too, and the list as of today is:
> ar, ca, cs, da, de, eu, fa, fi, fr, ga-IE, he, hu, is, ja, ja-JP-mac,
> lt, nn-NO, pl, pt-BR, ru, sk, sv-SE, te, tr, vi, zh-CN, zh-TW
(recheck history) ;-)
Francesco
flod (Francesco Lodolo)
> Actually there were also "it" and "nb-NO" before your last
> rearrangement (recheck history) ;-)
bug :-[
> Removing [it] and [nb-NO] from the status whiteboard, as these have already
> landed. I'm giving a post-factum r+ for these, but please don't land other
> locales just yet. We will mass-add Mibbit soon.
Sorry for the landing without approval: since that file is inside the
chrome folder, when English was updated I marked the string as "keep
original" and committed it with other files.
Unfortunately it's quite difficult to avoid this kind of error (for
example it's not a problem for searchplugins or bookmarks, since they're
outside of browser\chrome) :-(
Francesco
Staś Małolepszy
Yes, I know. But both 'it' and 'nb-NO' already added Mibbit on the 1.9.1
branch (..ekhem... without review...ekhem...;) ):
I removed them from the bug to make sure we don't add it twice (although
the script we're using should handle cases like these).
-Staś
flod (Francesco Lodolo)
> Yes, I know. But both 'it' and 'nb-NO' already added Mibbit on the
> 1.9.1 branch (..ekhem... without review...ekhem...;) ):
browser\chrome:
1) the English string is updated when I pull from the hg repository
2) I update the "browser" product inside Mozilla Translator
3) The string is marked as "keep original", so the changed string is
added to my locale when I export
If the change lands with a lot of other strings, it's quite easy to miss
it (for example I committed that change to Mozilla1.9.1 inside a group
of 11 files,
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/it/rev/0164e359938b).
Just to be sure: which parts need an approval before landing?
* /browser/chrome/browser-region/region.properties
* /browser/searchplugins/
/browser/profile/bookmarks.inc
Am I missing something else?
Francesco
Axel Hecht
Actually, bookmarks.inc is rather safe and sound these days, so changing
that is fine.
There are no other restrictions to the tree.
What really triggers my interest, what does "marked as keep original"
mean? Like, filter.py knows that those strings in region.properties can
differ and that difference can be ignored. That might not help a java
app, I'd just like to understand the concept there.
Axel
flod (Francesco Lodolo)
> What really triggers my interest, what does "marked as keep original"
> mean? Like, filter.py knows that those strings in region.properties
> can differ and that difference can be ignored. That might not help a
> java app, I'd just like to understand the concept there.
Translator: if a string is marked as "keep original", the localization
will be ignored (usually you leave it blank) and the original string
will be used for exports.
This is useful for strings that don't need to be localized, like a
string containing only "&brandshortname;" or URLs: if the original
string changes, I don't need to update my localization since only the
English string is considered.
Francesco
Axel Hecht
Smells like a great RFE for MT :-)
Axel
Ricardo Palomares Martínez
My nose is clogged. :-) What Flod describes is what MT is already
doing (since I started using it, seven years ago, BTW).
If you mean that MT could do what filter.py, where is filter.py, so I
can take a look to it? What I proposed before in this thread was to
standardize a localization note so L10N tools can warn the localizer
if he/she changes sensitive files (or even individual keys) that
require explicit approval before landing. That would be better that
harcoding a check, IMHO, if that's what filter.py does.
Ricardo
Ricardo Palomares Martínez
> If you mean that MT could do what filter.py, where is filter.py, so I
> can take a look to it? What I proposed before in this thread
Well, not this thread, but this:
http://groups.google.com/group/mozilla.dev.l10n/msg/82fa22c79ee40b80
Ricardo
Axel Hecht
http://mxr.mozilla.org/mozilla1.9.1/source/browser/locales/filter.py is
the one for Firefox 3.5
There's really no other way for compare-locales than to code up that
information somehow. Might be that doing it as python method isn't the
most accessible way of doing it for software in other languages,
granted. At least it's not hard-coded inside the perl code of a
comparison code itself, but packaged as part of the source ;-)
What I figured is that if other tools would read filter.py, they could
make an educated guess on how to present the given strings to the user.
With the experience we have so far, I wonder if the regexps in that code
are general enough to convert the filter.py files we have in the tree
into something more generic.
http://mxr.mozilla.org/comm-central/find?text=&kind=text&string=filter.py has
the list of those, not sure if the information is totally right in those
(I only own one of them).
That's independent of adding localization notes about review
requirements, surely.
Axel
Staś Małolepszy
> I'm going to mass-add Mibbit on 1.9.1 branch for these locales tomorrow
> morning, somewhere around 9 AM CET / 7 AM UTC / 12 AM (midnight) PDT.
> I'm going to update my local clones first of course in order minimize
> the risk of merge conflict and then post here again to report when I'm
> done.
I'm going to add Mibbit now. Should take me up to 30 minutes.
-Staś
Staś Małolepszy
> Staś Małolepszy wrote:
>
>> I'm going to mass-add Mibbit on 1.9.1 branch for these locales tomorrow
>> morning, somewhere around 9 AM CET / 7 AM UTC / 12 AM (midnight) PDT.
>> I'm going to update my local clones first of course in order minimize
>> the risk of merge conflict and then post here again to report when I'm
>> done.
>
> I'm going to add Mibbit now. Should take me up to 30 minutes.
Done. I have added Mibbit to the following locales:
ar, ca, cs, da, de, eu, fa, fi, fr, ga-IE, he, hu, id, is, ja,
ja-JP-mac, lt, nn-NO, pa-IN, pl, pt-BR, ru, sk, sq, sv-SE, te, tr, vi,
zh-CN, zh-TW
Hopefully all is good. Please don't hesitate to ping me if I caused any
trouble in your hg repo.
(From now on, please file individual bugs for locales that aren't onthat
list and yet would like to add Mibbit too.)
Thanks,
Staś Małolepszy
> Hopefully all is good. Please don't hesitate to ping me if I caused any
> trouble in your hg repo.
Three more things:
1. *Please remember to |hg pull -u| in your clone.*
2. I only landed on the 1.9.1 branch. If you're actively working in
l10n-central too, just |hg pull -u| in your 1.9.1 clone and |hg push
ssh://hg.mozilla.org/l10n-central/{your_locale}|. This will push my
commit to central, too. No review is required here, because the
changeset already exists.
3. *Please remember to |hg pull -u| in your clone.*
Thanks!
Staś
PS Oh, did I mention that you'll have to |hg pull -u| in your clone? :)
Axel Hecht
> Staś Małolepszy wrote:
>
>> Hopefully all is good. Please don't hesitate to ping me if I caused any
>> trouble in your hg repo.
>
> Three more things:
>
> 1. *Please remember to |hg pull -u| in your clone.*
>
> 2. I only landed on the 1.9.1 branch. If you're actively working in
> l10n-central too, just |hg pull -u| in your 1.9.1 clone and |hg push
> ssh://hg.mozilla.org/l10n-central/{your_locale}|. This will push my
> commit to central, too. No review is required here, because the
> changeset already exists.
Correction:
If you're already working on independent repos for 1.9.1 and 1.9.2,
i.e., the revisions on the two diverged, you won't be able to push from
1.9.1 to l10n-central.
No bad, though, there's help in hg:
Look at the pushlog for your 1.9.1 hg repo to find the url for his
changeset. In the case of sk, that would be
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/sk/rev/b54ab3851548
In the head, that has a link to "raw", in this case, linking to
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/sk/raw-rev/b54ab3851548.
Copy that url, and on the command line in your l10n-central repo, do
hg import
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/sk/raw-rev/b54ab3851548
That will add a changeset to your repo with stas' patch, comment, and
ownership.
You can have local commits that are not yet pushed, but you probably
shouldn't have uncommitted changes in your repo.
Please don't take the above link and just replace 'sk' with whatever
your locale code is, the revision number won't work. You need to grab
the right link on your 1.9.1 repo.
HTH
Axel
PS: No idea on tortoise and friends, no.