AMO compatibility dashboard strings
Justin Scott
The add-on compatibility dashboard is now localizable and the strings
were merged from en-US to all locales here:
http://viewvc.svn.mozilla.org/vc?view=rev&revision=21755
You can check out the compatibility center here:
https://addons.mozilla.org/en-US/firefox/compatibility
We'll be pointing more and more people to this dashboard as we get
closer to the release of Firefox 3.1, as well as future versions.
If you have any questions, please let me know.
Thanks
Justin
Nukeador
production server, since most of them have a two weeks delay since they
are translated and committed. I try to keep es-ES translation up to date
but I often find strings in English for weeks :P
Regards.
--
Nukeador
Clave PGP: http://www.nukeador.com/pgp/
Pascal Chevrel
> El 27/01/09 00:53, Justin Scott escribió:
>>
> It would be useful to know when the translations are updated to the
> production server, since most of them have a two weeks delay since they
> are translated and committed. I try to keep es-ES translation up to date
> but I often find strings in English for weeks :P
>
> Regards.
>
Also, please put in comments what the variables are supposed to be
replaced with, strings like this one are rather cryptic:
#: views/compatibility/dashboard.thtml:63
#, fuzzy
msgid "compatibility_developers_user_count"
msgstr "%1$s %2$s users (%3$s% of total)"
Thanks
Pascal
Justin Scott
this Thursday, and on the Thursday 3 weeks from that.
If your updates are checked in before the release is tagged (probably
Wednesday night?) it will go live this Thursday.
Justin Scott
out of the files by the automated scripts, but if that's not the case I
will gladly add comments in the future.
The string you mentioned might say something like:
"942 Firefox 3.1 users (34% of total)"
where
1 = 942
2 = Firefox 3.1
3 = 34
Developers can use the tool to determine how many of their active daily
users are already using a beta version, like Firefox 3.1.
Pascal Chevrel
> It was my understanding that non-gettext parsable comments are stripped
> out of the files by the automated scripts, but if that's not the case I
> will gladly add comments in the future.
>
> The string you mentioned might say something like:
> "942 Firefox 3.1 users (34% of total)"
> where
> 1 = 942
> 2 = Firefox 3.1
> 3 = 34
>
Thanks Justin,
If you look at the po, there are many strings with comments using this
format that are preserved:
# %1 is the add-on count, %2 the category name
It is very useful, to give you an example,for my language I have to move
the strings from:
%1$s %2$s users (%3$s% of total)
to:
%1$s utilisateurs de %2$s (%3$s% du total)
Cheers
Pascal
Francesco Lodolo
> AMO release cycles are every 3 weeks. We are doing a push to
> production this Thursday, and on the Thursday 3 weeks from that.
> If your updates are checked in before the release is tagged (probably
> Wednesday night?) it will go live this Thursday.
days, put in the middle of a workweek, are not enough if you really care
about l10n in AMO.
These days I have problems (work and real life) that keep me away from
home and a computer with all the software that I use for the
localization process. This mean that I'll get English strings for 3
weeks on the localized site? That's simply absurd.
Francesco
Axel Hecht
You're mixing plurals (# of users) with genders (product), so
localizations will need to work around this twice in one sentence. That
said, do we support gettext plural forms on AMO? Then we could fix at
least one of the two.
Anyway, when mixing content this wildly, you should understand that
while this sentence is OK in the English UI, it will sound awkward in a
bunch of other languages. In some cases there might be slightly less
good options in English which make for a better UE if localized.
Axel
Anas Husseini
plural-form strings are treated so (like: 'Weekly Downloads', 'Daily Active
Users', etc). This is one of them. I hope that will be fixed.
Regards
- Anas
> _______________________________________________
> dev-l10n-web mailing list
> dev-l1...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n-web
>
--
Experience is something you don't get until just after you need it.
Nukeador
> Il 27-01-2009 6:13, Justin Scott ha scritto:
>> production this Thursday, and on the Thursday 3 weeks from that.
>> If your updates are checked in before the release is tagged (probably
>> Wednesday night?) it will go live this Thursday.
> days, put in the middle of a workweek, are not enough if you really
> care about l10n in AMO.
>
> These days I have problems (work and real life) that keep me away from
> home and a computer with all the software that I use for the
> localization process. This mean that I'll get English strings for 3
> weeks on the localized site? That's simply absurd.
weeks for a push is absurd when a translation is valid code.
By the way, es-ES is updated with revision 21799, I hope to be in time.
Wil Clouser
> O/H Nukeador έγραψε:
>>> Il 27-01-2009 6:13, Justin Scott ha scritto:
>>>> production this Thursday, and on the Thursday 3 weeks from that.
>>>> If your updates are checked in before the release is tagged (probably
>>>> Wednesday night?) it will go live this Thursday.
>>>>
>>> days, put in the middle of a workweek, are not enough if you really
>>> care about l10n in AMO.
>>>
>>> These days I have problems (work and real life) that keep me away from
>>> home and a computer with all the software that I use for the
>>> localization process. This mean that I'll get English strings for 3
>>> weeks on the localized site? That's simply absurd.
>> I agree with Francesco, even if you keep your translations up to date, 3
>> weeks for a push is absurd when a translation is valid code.
Hey,
Speeding up the L10n pushes is something that is on my list to look in
to, but a great solution doesn't jump out at me.
L10n is tied directly to all the rest of our code changes because of the
way AMO is tagged/pushed. Our production tag is just trunk tagged at a
revision (if you want to be technical, trunk is considered an "external"
for our production tag). This means to get new code on the tag we have
to change the revision which is an all-or-nothing change - we get all
changes, not just L10n.
We've been doing this for years, but it's clearly not ideal for L10n so
I'm considering other options. Two that come to mind are:
1) Tag like everyone else. Copy/merge trunk into the production tag
every time (as recommended by the SVN book). This is a lot more time
consuming then what we're doing now but it's possible.
2) Break the /locale/ folder into it's own external. We could tag L10n
separately which would let us update it whenever we want (or really,
automatically, say, every 20 minutes or something). This is convenient
but it feels wrong because the L10n is such an integral part of the site
that calling it an "external" seems mislabeled. A minor complaint,
perhaps.
I'm leaning towards #2 but am happy to hear input. I'll also bring it
up at the AMO meeting today.
Thanks,
Wil
Ehsan Akhgari
> Γιώργος Φιωτάκης wrote:
>>
>> O/H Nukeador έγραψε:
>>>>
>>>> Il 27-01-2009 6:13, Justin Scott ha scritto:
>>>>>
>>>>> production this Thursday, and on the Thursday 3 weeks from that.
>>>>> If your updates are checked in before the release is tagged (probably
>>>>> Wednesday night?) it will go live this Thursday.
>>>>>
>>>>
I also think that option 2 is the way to go here, barring the paradox
of calling it external. One point though: when a change lands on
trunk which introduces new strings, and those strings are merged into
locales, the locales would contain those new strings. Now, if a
change on trunk removes strings and that removal is merged into
locales, the locales shouldn't be pushed to production before the code
itself is, otherwise there will be missing strings (which would be
replaced by gettext keys -- ugly). That won't be an issue of course
if changes including removal of strings are merged into locales at the
time they're pushed to production rather than the time they land on
trunk. This will cause the preview server to have some extra strings
for a while, but that won't hurt anyone I guess.
--
Ehsan
<http://ehsanakhgari.org/>
Francesco Lodolo
> so I'm considering other options. Two that come to mind are:
>
> 1) Tag like everyone else. Copy/merge trunk into the production tag
> every time (as recommended by the SVN book). This is a lot more time
> consuming then what we're doing now but it's possible.
>
> 2) Break the /locale/ folder into it's own external. We could tag
> L10n separately which would let us update it whenever we want (or
> really, automatically, say, every 20 minutes or something). This is
> convenient but it feels wrong because the L10n is such an integral
> part of the site that calling it an "external" seems mislabeled. A
> minor complaint, perhaps.
fails in one direction: the possibility for a localizer to decide when
the localization is ready to be published.
AMO is a complex application, we have a lot of problems with long words
and strings are sometimes misleading (think about the review/reviewer):
as a result you always need to check your work on stage, pushing the
localization on SVN, and the .po file online is not always ready to go
public.
From my perspective (as a localizer), the best solution would be to
have two different repositories, one for stage and one for the public
site, or at least the possibility to identify the file ready for the
publication (different folders?). Sincerely I don't know if this makes
sense for developers or IT guys.
Francesco
Axel Hecht
Sounds more like a branch instead of a tag to me.
Axel
Anas Husseini
To solve that, perhpas it is possible to make svn pushes update a testing
server (for instance http://preview.addons.mozilla.org/ab-CD), adn when the
localizer is satisfied he can apply the changes on the production server too
(perhaps an option provided in Localizer Tools). That way, there is no need
for 2 svn repos.
Regards
- Anas