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 s...@mozilla.com.)
If you have any questions, please don't hesitate to e-mail me directly at s...@mozilla.com or reply in this thread.
... and wish me luck :)
Best, Staś
-- Staś Małolepszy Mozilla L10n driver +48 600462291 +33 643800452
> 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
Actually there were also "it" and "nb-NO" before your last rearrangement (recheck history) ;-)
Il 31-03-2009 18:30, flod (Francesco Lodolo) ha scritto:
> Actually there were also "it" and "nb-NO" before your last > rearrangement (recheck history) ;-)
Ops, I checked the list in your mail and missed the last comment in the 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) :-(
flod (Francesco Lodolo) wrote: > Il 31-03-2009 18:24, Staś Małolepszy ha scritto: >> 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 > Actually there were also "it" and "nb-NO" before your last rearrangement > (recheck history) ;-)
Yes, I know. But both 'it' and 'nb-NO' already added Mibbit on the 1.9.1 branch (..ekhem... without review...ekhem...;) ):
> Yes, I know. But both 'it' and 'nb-NO' already added Mibbit on the > 1.9.1 branch (..ekhem... without review...ekhem...;) ):
As explained, the main problem is that region.properties is inside 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
>> Yes, I know. But both 'it' and 'nb-NO' already added Mibbit on the >> 1.9.1 branch (..ekhem... without review...ekhem...;) ): > As explained, the main problem is that region.properties is inside > 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
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.
> 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.
"Keep original" is a flag that you can set on each string in Mozilla 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.
On 31.03.2009 22:52 Uhr, flod (Francesco Lodolo) wrote:
> Il 31-03-2009 22:07, Axel Hecht ha scritto: >> 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. > "Keep original" is a flag that you can set on each string in Mozilla > 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.
Axel Hecht wrote: > On 31.03.2009 22:52 Uhr, flod (Francesco Lodolo) wrote: >> Il 31-03-2009 22:07, Axel Hecht ha scritto: >>> 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. >> "Keep original" is a flag that you can set on each string in Mozilla >> 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.
> Smells like a great RFE for MT :-)
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 Palomares Martínez wrote: > 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
> Axel Hecht wrote: >> On 31.03.2009 22:52 Uhr, flod (Francesco Lodolo) wrote: >>> Il 31-03-2009 22:07, Axel Hecht ha scritto: >>>> 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. >>> "Keep original" is a flag that you can set on each string in Mozilla >>> 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. >> Smells like a great RFE for MT :-)
> 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.
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=filte... 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.
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.
-Staś
-- Staś Małolepszy Mozilla L10n driver +48 600462291 +33 643800452
>> 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ś
-- Staś Małolepszy Mozilla L10n driver +48 600462291 +33 643800452
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.
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? :)
-- Staś Małolepszy Mozilla L10n driver +48 600462291 +33 643800452
>> 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
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.
|
