Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Calendar: Localization of Timezones
37 views
Skip to first unread message
Philipp Kewisch
Nov 15, 2011, 10:28:47 AM11/15/11
to
Hello Folks,
I recently pushed bug 647232 and bug 406579 to comm-aurora and
comm-beta. I had the hopes that adding the timezone strings to the
filter.py has the effect of those strings not needing to be translated.
It seems I am wrong and now all locales are red. I'm sorry about that. I
will try to find a solution today and if that doesn't work out backout
the patches that change the strings.
I'd also like to hear some input on how we should progress with the
timezones extension from an l10n standpoint: Timezones come out more
often than releases, and especially if an important change happens just
after a release (like the Russian timezone change) it would be great to
offer the timezones extension more quickly.
Currently, each timezone can be localized. The English text is something
like "Europe/Berlin". In most timezone updates a new rule is added or an
old rule is deleted, so in theory this would mean that each time
localizers need to handle this.
I'd like to make this optional somehow, since its a high amount of
strings and some locales might opt to just use the en-US names. It seems
just adding the prefix to filter.py won't help us, maybe someone has a
different solution?
Thanks
Philipp
I recently pushed bug 647232 and bug 406579 to comm-aurora and
comm-beta. I had the hopes that adding the timezone strings to the
filter.py has the effect of those strings not needing to be translated.
It seems I am wrong and now all locales are red. I'm sorry about that. I
will try to find a solution today and if that doesn't work out backout
the patches that change the strings.
I'd also like to hear some input on how we should progress with the
timezones extension from an l10n standpoint: Timezones come out more
often than releases, and especially if an important change happens just
after a release (like the Russian timezone change) it would be great to
offer the timezones extension more quickly.
Currently, each timezone can be localized. The English text is something
like "Europe/Berlin". In most timezone updates a new rule is added or an
old rule is deleted, so in theory this would mean that each time
localizers need to handle this.
I'd like to make this optional somehow, since its a high amount of
strings and some locales might opt to just use the en-US names. It seems
just adding the prefix to filter.py won't help us, maybe someone has a
different solution?
Thanks
Philipp
Axel Hecht
Nov 15, 2011, 12:16:06 PM11/15/11
to
they can't just flow down the channels?
Next up, do you really want to remove timezones from l10n? Like, if
you'd set them to False in filter.py, they're all ignored, and why add
the to l10n in the first place then? You could go for "report", which is
what we've done for Lorentz, they get shown, but they're not claimed to
be "missing".
Technically, the problem with your landing is probably that the build
logic doesn't trigger builds on filter.py changes, filed
https://bugzilla.mozilla.org/show_bug.cgi?id=702652 and I'm triggering
new builds now.
Axel
Iacopo Benesperi
Nov 15, 2011, 4:19:03 PM11/15/11
to
Philipp Kewisch ha scritto:
static. Anyway, on the dashboard everything is green for my locale. Is
this because you reverted the changes, or am I not just getting what's red?
bye,
Iacopo
> I recently pushed bug 647232 and bug 406579 to comm-aurora and
> comm-beta. I had the hopes that adding the timezone strings to the
> filter.py has the effect of those strings not needing to be translated.
>
> It seems I am wrong and now all locales are red. I'm sorry about that. I
> will try to find a solution today and if that doesn't work out backout
> the patches that change the strings.
I'm quite amazed, too. I thought timezones were something more or less
> comm-beta. I had the hopes that adding the timezone strings to the
> filter.py has the effect of those strings not needing to be translated.
>
> It seems I am wrong and now all locales are red. I'm sorry about that. I
> will try to find a solution today and if that doesn't work out backout
> the patches that change the strings.
static. Anyway, on the dashboard everything is green for my locale. Is
this because you reverted the changes, or am I not just getting what's red?
bye,
Iacopo
Axel Hecht
Nov 15, 2011, 6:39:16 PM11/15/11
to
string changes, and the dashboard only ran for the string changes,
originally reporting missing strings. I reran the builds, which picked
up the change to filter.py, too, which turned the builds back green.
That doesn't mean that the dashboard would tell you which timezone
strings are up for translation at this point, on any branch. Or any
tools trying to use filter.py to decide what to show or not.
Axel
Iacopo Benesperi
Nov 15, 2011, 7:37:57 PM11/15/11
to
Axel Hecht ha scritto:
manually and look for differencies?
If this change affects also the trunk, Mozilla Translator should be able
to detect it, and then a transplant should do. Otherwhise, if the trunk
was updated before and it's already up to date, I'd only need to copy
the strings from trunk to the two branches?
Iacopo
> That doesn't mean that the dashboard would tell you which timezone
> strings are up for translation at this point, on any branch. Or any
> tools trying to use filter.py to decide what to show or not.
Does this mean that I should check the two branches (and the trunk?)
> strings are up for translation at this point, on any branch. Or any
> tools trying to use filter.py to decide what to show or not.
manually and look for differencies?
If this change affects also the trunk, Mozilla Translator should be able
to detect it, and then a transplant should do. Otherwhise, if the trunk
was updated before and it's already up to date, I'd only need to copy
the strings from trunk to the two branches?
Iacopo
smo
Nov 16, 2011, 4:58:29 AM11/16/11
to
> I'd like to make this optional somehow, since its a high amount of
> strings and some locales might opt to just use the en-US names. It seems
> just adding the prefix to filter.py won't help us, maybe someone has a
> different solution?
>
> Thanks
> Philipp
Maybe split the collection into those already localized (including
Evropa/Berlin)
and those new? I do not think any new time zones will turn up in the
existing
places, so no bad blood from current users. So HappyFeet/New Georgia
e.g.
can stay in English for what I care. I just would not like to provoke
sl users
with Ljubljana/Slovenia.
Regards
smo
Michael Bauer
Nov 16, 2011, 5:46:08 AM11/16/11
to dev-...@lists.mozilla.org
I'm afraid I have no technical suggestions to make but timezones do
shift around. Samoa recently changed time zones to tie in more easily
with NZ/Australian time, Venezuela shifted by 30 minutes in 2007.
Sometimes it *can* happen very fast.
Michael
16/11/2011 09:58, sgrìobh smo:
shift around. Samoa recently changed time zones to tie in more easily
with NZ/Australian time, Venezuela shifted by 30 minutes in 2007.
Sometimes it *can* happen very fast.
Michael
16/11/2011 09:58, sgrìobh smo:
Philipp Kewisch
Nov 16, 2011, 7:49:34 AM11/16/11
to
in the year so there have been 14 sets of changes alone this year. We
haven't been updating each version, so thats why it didn't show
before.
So the "report" thing sounds like what I need, how do I do this?
Return that string?
Axel Hecht
Nov 16, 2011, 9:35:57 AM11/16/11
to
is an example, and the only one we have in our trees right now, I'm afraid.
Axel
Philipp Kewisch
Nov 17, 2011, 2:56:25 AM11/17/11
to
On Nov 16, 3:35 pm, Axel Hecht <l...@mozilla.com> wrote:
> http://hg.mozilla.org/releases/mozilla-1.9.2/file/ad815619652f/browse...
re-trigger the l10n builds to make it visible.
I can fully understand that a localizer expects comm-beta and comm-
aurora to be string frozen, so I'm still not quite sure how to best
handle this in the future. As previously mentioned, timezone changes
happen quite often and waiting up to two releases with a max of 18
weeks for the timezones to be available sometimes just doesn't work
out.
Going one step further, I'd even like to offer timezone upgrades more
quickly in the future using some automation to detect if there is a
new timezones version and then use the timezones extension to provide
quick updates. Anyway, for now, some more questions about the process:
Do I understand correctly that with "report", I can happily push
timezone changes to aurora and beta, without causing extra pain for
localizers?
Is it acceptable to assume en-US strings for locales that opt to not
translate those last minute l10n changes?
What do I need to do on the build side? Run l10n-merge? Can it be run
for that directory only?
Philipp
> http://hg.mozilla.org/releases/mozilla-1.9.2/file/ad815619652f/browse...
> is an example, and the only one we have in our trees right now, I'm afraid.
Ok, I pushed this to all branches to see how it does. You may need to
re-trigger the l10n builds to make it visible.
I can fully understand that a localizer expects comm-beta and comm-
aurora to be string frozen, so I'm still not quite sure how to best
handle this in the future. As previously mentioned, timezone changes
happen quite often and waiting up to two releases with a max of 18
weeks for the timezones to be available sometimes just doesn't work
out.
Going one step further, I'd even like to offer timezone upgrades more
quickly in the future using some automation to detect if there is a
new timezones version and then use the timezones extension to provide
quick updates. Anyway, for now, some more questions about the process:
Do I understand correctly that with "report", I can happily push
timezone changes to aurora and beta, without causing extra pain for
localizers?
Is it acceptable to assume en-US strings for locales that opt to not
translate those last minute l10n changes?
What do I need to do on the build side? Run l10n-merge? Can it be run
for that directory only?
Philipp
Philipp Kewisch
Nov 17, 2011, 4:11:59 AM11/17/11
to
Note also, I have backed out the 2011n timezones patch (that contains
the string changes) on comm-beta until this is resolved.
the string changes) on comm-beta until this is resolved.
smo
Nov 18, 2011, 1:57:00 PM11/18/11
to
On 17 Nov., 10:11, Philipp Kewisch <kewi...@gmail.com> wrote:
> Note also, I have backed out the 2011n timezones patch (that contains
> the string changes) on comm-beta until this is resolved.
hi Phillipp:
> Note also, I have backed out the 2011n timezones patch (that contains
> the string changes) on comm-beta until this is resolved.
we probably met half a dozen times in Berlin, but not the way I wanted
to (g). Heres my two cents on the subject: I would not see any
problems with en-US updates for SL. Better correct, even if in en-US,
than incomplete / out-of-date.
Regards
smo
Axel Hecht
Nov 28, 2011, 11:38:32 AM11/28/11
to
probably want to have the en-US strings in content, too.
I'm still not convinced that this is the right way to ship this data,
but I don't have a better suggestion.
Axel
0 new messages