From 50 to 100 locales
Axel Hecht
we'd like to collect some data and idea on how to get from the 50
locales and releasing 40 to a hundred.
Clearly, everybody feels the load of releasing a Mozilla product in 40
languages, and while we got the job done, it's about time to look ahead
and point at the places where going further leads to trouble.
So to start the discussion, it'd be a good idea to collect how much one
locale of the 40 currently 'costs'. How much time is spent on a locale
day-to-day (tinderbox build times come to mind), and how much man power
and computing resources do we need for a release? How much for an
update, how much for a major new release? I would hope to get
guestimates or number from folks like localizers, drivers, build, QA, BD
and product.
In parallel, we should collect ideas on how to make l10n easier, and
improve the quality over all. I have some, but I'll keep those for a
follow up.
This discussion should include options on the goal and expectations to
be set on the beast at large, too.
Axel
StartCom Linux Maintainer
Marcelo Poli
> So to start the discussion, it'd be a good idea to collect how much one
> locale of the 40 currently 'costs'. How much time is spent on a locale
> day-to-day (tinderbox build times come to mind), and how much man power
> and computing resources do we need for a release? How much for an
> update, how much for a major new release? I would hope to get
> guestimates or number from folks like localizers, drivers, build, QA, BD
> and product.
Tinderbox, CVS, modification and CVS again.
When a release comes close, times rise up to 2 or 3 hours.
An update needs only QA time as there's almost no modifications in l10n.
Help is completely different. It needs a complete revision of the file.
The rest of the small team is in charge of QA, help files and other
products in the near future. None of them knows about CVS and none of
them wants to learn about CVS, so I must send them the files to
translate and they send them back to me translated.
I'm going to ask for help in some computer magazines to increase the
number of members involved in translation.
>
> In parallel, we should collect ideas on how to make l10n easier, and
> improve the quality over all. I have some, but I'll keep those for a
> follow up.
Should be great to keep a single communication channel. Today we don't
know if we need to watch news.mozilla.org, wiki.mozilla.org,
developer.mozilla.org, bugzilla.mozilla.org.
There's no "corkboard" telling us the wiki pages, how, where, etc.
Marek Stępień
> So to start the discussion, it'd be a good idea to collect how much one
> locale of the 40 currently 'costs'.
As Cedric wrote in .110n, it takes approximately 30-40 minutes a day
(which may mean 3-4 hours once a week) to keep a l10n up-to-date. I'm
talking about normal situations of course, like e.g. last two weeks of
Thunderbird 2 and Fx/Tb trunk development.
For an update it takes less time, even zero if there are no changes
pending in the l10n. For example, releasing 2.0(.0).1 in Polish would
be a little more time-consuming than releasing 1.5.0.7, as we have
patches pending, but of course nothing like the 2.0 release which
required lots of time.
As a final release is approaching, there amount of testing that needs
to be done is getting higher, so before a release it takes a few hours
a day. (Well, for a few weeks this summer I almost felt like Fx2 l10n
was my full time job on a night shift ;-))
> In parallel, we should collect ideas on how to make l10n easier, and
> improve the quality over all. I have some, but I'll keep those for a
> follow up.
Some ideas that are easy to implement:
* get rid of all the obsolete and confusing content from MLP pages
* finalize all the HOWTOs and keep them in one place (e.g. why the hell
is this: http://developer.mozilla.org/en/docs/Create_a_new_localization
on MDC instead of wiki.m.o L10n project pages?)
* have more people to review and accept new l10ns, so that folks don't
need to wait several months to get their l10n into cvs.
* have more time between the RCs for the l10n teams to patch stuff.
This is really important for the locales that are not kept up-to-date
through the whole development process, i.e those that are only
synchronized with en-US just before the release.
* allow creating language packs without the need of going through all
the build process. Not all l10n teams consist of hackers. :)
And some not easy ones:
* move en-US localization to the l10n cvs (I suppose this won't happen
for Fx3, but maybe for Fx 4?)
* consider creating a webtool like Ubuntu's launchpad.net/rosetta that
would let the localizers just use an easy web interface for l10n.
--
Marek Stępień <mar...@aviary.pl>
AviaryPL - polski zespół lokalizacyjny Mozilli
http://www.firefox.pl/ | http://www.mozilla.org.pl/
Cédric Corazza
> And some not easy ones:
>
> * move en-US localization to the l10n cvs (I suppose this won't happen
> for Fx3, but maybe for Fx 4?)
What for Marek?
Marek Stępień
>> And some not easy ones:
>>
>> * move en-US localization to the l10n cvs (I suppose this won't happen
>> for Fx3, but maybe for Fx 4?)
>
> What for Marek?
It's not that I need this for myself, but this is what the new
localizers have the most trouble with - getting
the original en-US files in the correct structure.
Ricardo Palomares Martinez
> we'd like to collect some data and idea on how to get from the 50
> locales and releasing 40 to a hundred.
That's ambitious, and not only requires from Mozilla Foundation, but
something more important IMHO: there have to be volunteers willing to
join the effort. Galician translation comes to my mind: since the
previous translator quit, we have seen several attempts to reactivate
it without any success.
> So to start the discussion, it'd be a good idea to collect how much one
> locale of the 40 currently 'costs'. How much time is spent on a locale
> day-to-day (tinderbox build times come to mind), and how much man power
> and computing resources do we need for a release?
Since I'm quitting from Firefox 3.0 l10n for es-ES and Andres is
actually gone for a while, I've been asking for replacement and told
people willing to join to expect about an hour per day in the last six
months (including everything day-to-day, updating CVS, checking
tinderboxes, contributing this newsgroup, reviewing bugs, etc.), with
increasing availability in two or three months before a release. I'm
actually asking for two people, so each of them doesn't need so much
availability.
> How much for an update, how much for a major new release?
Little or no time is required for updates, a LOT is required just
before a major release.
> In parallel, we should collect ideas on how to make l10n easier, and
> improve the quality over all. I have some, but I'll keep those for a
> follow up.
I've been localizing for more than four years now. I can't find
anything specially difficult, except maybe the administrative tasks
(bug procedures, trademark reviews, etc.). Contrary to other's
opinion, I don't see any problem with having several formats (RDFs are
a bit ugly, but not so much), and I really think that keeping up to
date the help contents using a wiki would be very harmful, since
keeping track of changes would be more difficult.
However, I see big problems to start a new translation. Even now, I
never know if I should look for documentation at Wiki.mozilla.org or
at developer.mozilla.org (when I'm looking for info, I don't care if
it is a final version or work in progress, as long as I'm able to find
it, and now we must search twice, maybe finding contradictory info in
both sites).
I also regard http://wiki.mozilla.org/L10n:Home_Page as the current
MLP home page; after all, it was created as quick way to solve the
obsolete info at the "official" MLP home page
(http://www.mozilla.org/projects/l10n/). But then, it turns out that
the wiki L10n home page itself already has broken links, obsolete info
(why do we still have info about 1.0.x?) and I think the most
important info for newcomers is buried at the bottom of the page. Not
a big improvement, really.
The problem (as always) is with manpower to do the cleanup, and some
time to draw a sensible outline. Some time ago, you discarded my
suggestion of planning the documentation structure at MDC before
adding content, because you saw it as too much planning and little
actual work. I keep thinking that a lot of content that is too
difficult to find is not of much help, either.
For established localization teams, I think that most of us will agree
that accesskeys are the greatest PITA. Checking accesskeys and trying
to make them compliant to XUL Accesskey FAQ and Policies
(http://developer.mozilla.org/en/docs/XUL_Accesskey_FAQ_and_Policies,
which needs a reality check itself if it aims to really be a policy
instead of suggestions) is annoying and mechanic; it therefore should
be done by machines, i.e. by CAT software like MozillaTranslator,
LocaleInspector or Translate Toolkit, but it can't be done because
there is no way for the tool to know where the accesskey can conflict
just looking at locale files (parsing XUL files would be needed, and
localizers don't usually check out anything not under /locale/).
If we could come up with a good design to remove ambiguity in
accesskeys usage (I have even catched an accesskey entity in TB that
was present in messenger/chrome/messenger.dtd but it was actually
being used from other file in editor/ui/...), so the locale files were
enough to detect if, for instance, an accesskey conflict is going to
happen (the same letter used twice in a dialog or a dropdown menu)
that would be a big step forward.
Defining and adding QA checks to CAT tools is always good, IMHO. I've
trying to advance a little bit in MT with that, and I'm pretty sure
that a lot of room for improvement remains (but, surprisingly for me,
MT users didn't see that as a MUST when I talked about adding it).
Autotranslate is of course something desirable, but it's somewhat
complex to add it to MT because of its current design model (with MT,
everything is loaded to RAM, which uses a LOT, but that doesn't mean
that searches for auto-translation are going to be quick). Also, I'm
already late in my schedule for my own replacement for MT, which will
be my final year project and should include all of this and other
features.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Axel Hecht
> Cédric Corazza napisał(a):
>>> And some not easy ones:
>>>
>>> * move en-US localization to the l10n cvs (I suppose this won't happen
>>> for Fx3, but maybe for Fx 4?)
>> What for Marek?
>
> It's not that I need this for myself, but this is what the new
> localizers have the most trouble with - getting
> the original en-US files in the correct structure.
>
There's a documented tool to do just that, l10n.mk.
I have some better ideas here, though, which will be part of a follow up
when I'm back in Berlin.
Axel
Axel Hecht
> Axel Hecht escribió:
>> So to start the discussion, it'd be a good idea to collect how much
>> one locale of the 40 currently 'costs'. How much time is spent on a
>> locale day-to-day (tinderbox build times come to mind), and how much
>> man power and computing resources do we need for a release? How much
>> for an update, how much for a major new release? I would hope to get
>> guestimates or number from folks like localizers, drivers, build, QA,
>> BD and product.
> If there are little changes I spend 15 minutes on wathcing this ng,
> Tinderbox, CVS, modification and CVS again.
> When a release comes close, times rise up to 2 or 3 hours.
> An update needs only QA time as there's almost no modifications in l10n.
> Help is completely different. It needs a complete revision of the file.
> The rest of the small team is in charge of QA, help files and other
> products in the near future. None of them knows about CVS and none of
> them wants to learn about CVS, so I must send them the files to
> translate and they send them back to me translated.
> I'm going to ask for help in some computer magazines to increase the
> number of members involved in translation.
Thanks for the infos here.
>>
>> In parallel, we should collect ideas on how to make l10n easier, and
>> improve the quality over all. I have some, but I'll keep those for a
>> follow up.
>
> Should be great to keep a single communication channel. Today we don't
> know if we need to watch news.mozilla.org, wiki.mozilla.org,
> developer.mozilla.org, bugzilla.mozilla.org.
> There's no "corkboard" telling us the wiki pages, how, where, etc.
Yes, we should be more clear about what we expect owners to do
communication wise.
Here's my scrap book:
Follow mozilla.dev.l10n, hopefully more. I'd expect localizers to be
interested in .planning and the respective application newsgroups, i.e.
mozilla.dev.apps.firefox and such.
But for the l10n communication channel, posts that affect l10n should be
cross-posted to .l10n, I know that our mikes are working hard on getting
that right, otherwise I'll follow up with a post.
With respect to bugzilla, for locale-specific issues, we want to be able
to file bugs and get them fixed. That's mostly setting up a bugzilla
component and watching the right bugmail accounts. I would expect that
that's just a minor additional hurdle.
Watching firef...@hotmail.com is a bit trickier, I should likely put
more emphasis that I use that alias to notify all owners about issues
affecting "a bunch" of locales. Usually I do that when I don't know how
many locales are affected. Owners should really watch
firef...@hotmail.com, independent on whether that's Firefox or
Thunderbird owners. I'm flexible here, though. We should have a central
alias, but I'm not sure if it has to be one for all or if we should have
one for each product.
There's only limited value in watching l1...@mozilla.com, AFAICT, though
folks interested in the broader picture are welcome to do that. Might
require good skills in screening bugmails, though.
Does that outline help? Then I'd take a stab and work on the
documentation of that. Or just pick up
http://wiki.mozilla.org/L10n:Ownership a bit more. Docs will show up in
other responses of mine in more detail.
Axel
Axel Hecht
The documentation front is a project of mine that got cut. Literally. I
had that on my agenda for FOSDEM 2006, you know :-(.
It took a lot of pages to create the MLP pages, and it seems to take
even more people to kill them. I'm pretty sure I won't be able to pull
that off alone, so I'd be more than glad to see some volunteers stepping
up and do baby steps. Shaver-keynote-small. Something like
http://developer.mozilla.org/en/docs/MDC:Existing_Content would probably
be a good start.
As for the wiki vs. devmo debate, the line between the two is blurry,
but well-enough defined to make "Create a new localization" a devmo
article. devmo is about developer documentation, wiki is more about
project organisation, and dumping ground.
In the end, people trying to start a localization would find the right
entry points for that in the developer documentation spot.
> * have more people to review and accept new l10ns, so that folks don't
> need to wait several months to get their l10n into cvs.
Actually, we should lower the bar before. The review requirements are
really high, and not really open source, IMHO.
I'd like to find some time to create some kind of testing build, which
would take, going from an incomplete localization, en-US entries as back
up and create builds for localizers to test.
Right now, this seems to be part of a bigger story to make l10n builds
more responsive, with better error reporting. Across the board, we
should try to get the turnaround time for a patch down. I have high
hopes for the buildbot work here, btw.
> * have more time between the RCs for the l10n teams to patch stuff.
> This is really important for the locales that are not kept up-to-date
> through the whole development process, i.e those that are only
> synchronized with en-US just before the release.
Would incomplete testing builds help here? So that localizers could work
better on chunks and get those tested?
> * allow creating language packs without the need of going through all
> the build process. Not all l10n teams consist of hackers. :)
I'm not sure this one is easy, there are so many nits in the details.
There is one idea floating in my head, which is to provide something
like a CD or DVD to ship to localizers containing all the stuff they'd
need. Like, a version of cygwin etc... with a single installer to kick
stuff off and set paths.
I would think that it's easier to create a CD from a reference platform
than to actually maintain two build processes. Or maybe our build
process get's that whacked that that's trivial.
> And some not easy ones:
>
> * move en-US localization to the l10n cvs (I suppose this won't happen
> for Fx3, but maybe for Fx 4?)
I don't really see the value in this one, see my other reply down the
thread.
> * consider creating a webtool like Ubuntu's launchpad.net/rosetta that
> would let the localizers just use an easy web interface for l10n.
On top of the general feeling contra-web-tool that I have, I wonder if a
webtool is really the way to get us to a 100.
This is going to be smaller languages in developing countries, and I
expect that offline tooling would be much more important than online
tooling here.
I see one exception, and that would be a glossary (I may have changed my
mind on using an external one). I think that finding out which terms
should be in a glossary and which don't necessarily need to be is
knowledge that calls out to be shared among localizations, and thus
using a webtool here would be good. Best if the glossary data could be
exported to be used offline, too.
Axel
Gervase Markham
> Since I'm quitting from Firefox 3.0 l10n for es-ES and Andres is
> actually gone for a while, I've been asking for replacement and told
> people willing to join to expect about an hour per day in the last six
> months (including everything day-to-day, updating CVS, checking
> tinderboxes, contributing this newsgroup, reviewing bugs, etc.), with
> increasing availability in two or three months before a release. I'm
> actually asking for two people, so each of them doesn't need so much
> availability.
An hour per day for six months? That's ridiculous.
Is that due to some requirement we have that a particular localisation
should always be building? If so, that seems silly to me. Why should a
localisation team not take a weekend once a month to catch up, during
the normal development cycle? OK, so more time is needed near releases,
but surely there's no reason for teams to have to update and build from
CVS, check tinderboxes, etc. every _day_?
Gerv
Axel Hecht
> Axel Hecht escribió:
>> we'd like to collect some data and idea on how to get from the 50
>> locales and releasing 40 to a hundred.
>
> That's ambitious, and not only requires from Mozilla Foundation, but
> something more important IMHO: there have to be volunteers willing to
> join the effort. Galician translation comes to my mind: since the
> previous translator quit, we have seen several attempts to reactivate
> it without any success.
Lowering the bar is gonna be key here, yes.
>> So to start the discussion, it'd be a good idea to collect how much one
>> locale of the 40 currently 'costs'. How much time is spent on a locale
>> day-to-day (tinderbox build times come to mind), and how much man power
>> and computing resources do we need for a release?
>
>
> Since I'm quitting from Firefox 3.0 l10n for es-ES and Andres is
> actually gone for a while, I've been asking for replacement and told
> people willing to join to expect about an hour per day in the last six
> months (including everything day-to-day, updating CVS, checking
> tinderboxes, contributing this newsgroup, reviewing bugs, etc.), with
> increasing availability in two or three months before a release. I'm
> actually asking for two people, so each of them doesn't need so much
> availability.
Anything in particular that makes you quit? I'd be happy to get a mail
on this, too.
Do any of the proposals in these threads so far sound like they could
change your mind?
>> How much for an update, how much for a major new release?
>
>
> Little or no time is required for updates, a LOT is required just
> before a major release.
>
>
>> In parallel, we should collect ideas on how to make l10n easier, and
>> improve the quality over all. I have some, but I'll keep those for a
>> follow up.
>
>
> I've been localizing for more than four years now. I can't find
> anything specially difficult, except maybe the administrative tasks
> (bug procedures, trademark reviews, etc.). Contrary to other's
> opinion, I don't see any problem with having several formats (RDFs are
> a bit ugly, but not so much), and I really think that keeping up to
> date the help contents using a wiki would be very harmful, since
> keeping track of changes would be more difficult.
Yeah, I hope that we'll be able to make end-user documentation less of
an optional nightmare.
Deploying more testing should probably be able to give better feedback
on technical bugs earlier in the development cycle, too.
> However, I see big problems to start a new translation. Even now, I
> never know if I should look for documentation at Wiki.mozilla.org or
> at developer.mozilla.org (when I'm looking for info, I don't care if
> it is a final version or work in progress, as long as I'm able to find
> it, and now we must search twice, maybe finding contradictory info in
> both sites).
Everybody understands that it's not the most trivial task to keep the
two apart, but there is a good line to use for that. One is project
planning and tracking, the other is developer documentation. There are
some pages which are fuzzy and could be on both, though.
> I also regard http://wiki.mozilla.org/L10n:Home_Page as the current
> MLP home page; after all, it was created as quick way to solve the
> obsolete info at the "official" MLP home page
> (http://www.mozilla.org/projects/l10n/). But then, it turns out that
> the wiki L10n home page itself already has broken links, obsolete info
> (why do we still have info about 1.0.x?) and I think the most
> important info for newcomers is buried at the bottom of the page. Not
> a big improvement, really.
I got scared yesterday. I tried to find the localization team list and
failed. I need to whack that page with a hammer.
Then again, it's a wiki, and everybody else could do that, too.
> The problem (as always) is with manpower to do the cleanup, and some
> time to draw a sensible outline. Some time ago, you discarded my
> suggestion of planning the documentation structure at MDC before
> adding content, because you saw it as too much planning and little
> actual work. I keep thinking that a lot of content that is too
> difficult to find is not of much help, either.
I refer to my other reply, we need to team up to get documentation up to
speed. I can't write it alone, let alone know which documentation needs
to be written.
> For established localization teams, I think that most of us will agree
> that accesskeys are the greatest PITA. Checking accesskeys and trying
> to make them compliant to XUL Accesskey FAQ and Policies
> (http://developer.mozilla.org/en/docs/XUL_Accesskey_FAQ_and_Policies,
> which needs a reality check itself if it aims to really be a policy
> instead of suggestions) is annoying and mechanic; it therefore should
> be done by machines, i.e. by CAT software like MozillaTranslator,
> LocaleInspector or Translate Toolkit, but it can't be done because
> there is no way for the tool to know where the accesskey can conflict
> just looking at locale files (parsing XUL files would be needed, and
> localizers don't usually check out anything not under /locale/).
Accesskeys are hard, and can't really be automated across the board. At
least for complex script languages like Japanese or Chinese, there are
no good accesskeys, which is likely why the current system is, well,
really flexible.
How does our code get to accesskeys? Does someone have a pointer to the
source that actually gets those from the doc? I have another testing
extension in the queue, which goes over parts of our UI, and I might be
able to add a testing step for accesskeys, if I find out what I need to
replicate.
> If we could come up with a good design to remove ambiguity in
> accesskeys usage (I have even catched an accesskey entity in TB that
> was present in messenger/chrome/messenger.dtd but it was actually
> being used from other file in editor/ui/...), so the locale files were
> enough to detect if, for instance, an accesskey conflict is going to
> happen (the same letter used twice in a dialog or a dropdown menu)
> that would be a big step forward.
>
> Defining and adding QA checks to CAT tools is always good, IMHO. I've
> trying to advance a little bit in MT with that, and I'm pretty sure
> that a lot of room for improvement remains (but, surprisingly for me,
> MT users didn't see that as a MUST when I talked about adding it).
My testing stuff focuses on testing as part of the build process, which
may just be because that's something I can control.
> Autotranslate is of course something desirable, but it's somewhat
> complex to add it to MT because of its current design model (with MT,
> everything is loaded to RAM, which uses a LOT, but that doesn't mean
> that searches for auto-translation are going to be quick). Also, I'm
> already late in my schedule for my own replacement for MT, which will
> be my final year project and should include all of this and other
> features.
What would autotranslate do?
Thanks for the input
Axel
John Gaunt
We've developed an online tool for translating Songbird into other
languages. The url is http://translate.songbirdnest.com/ Basically it
hosts the dtd and properties files that need to get translated and users
can translate them online, generate an XPI and install them in songbird
to test.
We don't have everything automated and working perfectly yet. Our web
engineer has to manually push some stuff into our builds still and we
haven't completely transferred to xpi based localizations but the site
is pretty slick.
John
(redfive)
Axel Hecht
Hi John,
I took a brief look at the site, and I found collaborative editing,
basically. Are there any features to support branches? One thing that
I'm interested in, too, is the chance of getting translations more
self-consistent, for example via glossaries.
Axel
Robert Kaiser
> An hour per day for six months? That's ridiculous.
Actually, doing SeaMonkey L10n with MozillaTranslator on trunk + branch,
keeping German packages for both of those current takes me an hour or
two every 1-2 weeks - and that's for a bigger amount of strings than
Firefox-only projects have, as I'm doing full SeaMonkey including even
chatzilla, venkman and inspector (not including help though, which is
done by a different team member).
Of course, that's for an experienced long-time localizer who has been
into Mozilla L10n for about 7 years now, and that's for only keeping an
existing L10n up-to-date with nightlies.
Releases take some extra work and testing, of course.
I think our biggest problem in increasing the amount of locales is not
as much the localizers' side (which can still be improved for sure), but
actually the MoCo side of things.
We need some way to efficiently manage testing, policy-reviewing and
building locales, cutting down on the time we need per-locale for that.
For QA, perhaps we could do some QA extension usable by multiple
Mozilla-related products that any tester (esp. locale testers) can
install and that would, through a button or such in its per-extension
pref window would just report back to some Mozilla server with the build
ID, locale, platform and whatever needed info, so the server-side
service could mark it as "tested" in a database. This way, localizers
can QA the builds and report back with a click that it works, giving us
a nice QA overview on the server side.
For most release builds, I think we don't need to go through a full
suite of tests for every platform/locale combination, as hopefully our
release process is in a state where the actual binaries are identical
for all locales, only the language .jar packs are different in the
actual build. In this case, in-deep testing for the en-US builds on all
platforms and a quick test if update and application display work
correctly on every locale/platrform combination should be enough.
I think cutting down on the time needed for QA on the MoCo side
per-locale is probably one of the keys to being able to handle a bigger
amount of locales.
Additionally, a fallback solution at least at build time so that
non-full localizations can be filled up to build full locales could
improve some processes, as such a mechanism would not only make it
harder to break builds with new strings, but also could be leveraged for
doing locales that only change parts of a different existing locale
(think en-US -> en-GB -> en-[CA|AU] and similar ones).
Robert Kaiser
Axel Hecht
Yes, totally. Cutting down on complexity in the localization process is
a nice to have, cutting down in the complexity of releasing a locale is
a must, as that's the point where we don't scale.
Great points throughout, it may actually be interesting to put some
ideas on different hooks, in particular the automated tests should
really be run by the build infrastructure.
> Additionally, a fallback solution at least at build time so that
> non-full localizations can be filled up to build full locales could
> improve some processes, as such a mechanism would not only make it
> harder to break builds with new strings, but also could be leveraged for
> doing locales that only change parts of a different existing locale
> (think en-US -> en-GB -> en-[CA|AU] and similar ones).
I somehow get the impression that content packs would be good to have.
Axel
Ricardo Palomares Martinez
> Ricardo Palomares Martinez wrote:
>> Since I'm quitting from Firefox 3.0 l10n for es-ES and Andres is
>> actually gone for a while, I've been asking for replacement and told
>> people willing to join to expect about an hour per day in the last six
>> months (including everything day-to-day, updating CVS, checking
>> tinderboxes, contributing this newsgroup, reviewing bugs, etc.), with
>> increasing availability in two or three months before a release. I'm
>> actually asking for two people, so each of them doesn't need so much
>> availability.
>
> An hour per day for six months? That's ridiculous.
>
Re-read. I'm not talking just about updating strings, but also keeping
up to date in mozilla.dev.l10n and our internal mailing list postings,
reviewing bugs, ocasionally downloading and testing localized
binaries... Maybe I've going too far with six months, but we started
caring about Firefox 2 by end June, and I know Andres needed more than
an hour to catch up with the 600+ strings new or updated. After that,
some days I've found no changes, but still I spent time with the other
things.
And then other considerations should be taken into accout: being a
localizer doesn't mean being a coder, not even an advanced computer
user, so many things some of us can be doing in automated ways could
be manual work for them. An hour can be more than needed for
experienced localizers, but ten minutes will be definitely not enough
for newcomers.
For instance, I've spent more than ten minutes to answer this. ;-)
Greg K Nicholson
> http://translate.songbirdnest.com/
If Mozilla had something like this or Ubuntu's Rosetta, I would be able
(and happy) to localise Firefox, Thunderbird et al. (albeit into
en-GB). Automatic updates for non-en-US nightlies wouldn't hurt, either.
Ricardo Palomares Martinez
> Ricardo Palomares Martinez wrote:
>> Since I'm quitting from Firefox 3.0 l10n for es-ES and Andres is
>
> Anything in particular that makes you quit? I'd be happy to get a mail
> on this, too.
Not that I mind to make the reasons public, but I think that would be
going off-topic, so I'll answer you by e-mail.
>
> I got scared yesterday. I tried to find the localization team list and
> failed. I need to whack that page with a hammer.
:-)
>
> Then again, it's a wiki, and everybody else could do that, too.
>
I would be scared to update the L10n main page without having been
told to do so. :-)
>
> I refer to my other reply, we need to team up to get documentation up to
> speed. I can't write it alone, let alone know which documentation needs
> to be written.
>
OK; what I would expect from you is (again, I'm stubborn) :-) to
outline a doc organization and/or main TOC and let us write it.
Something I think is already happening is that MT documentation is
being updated in the wiki. I update the OpenDoc user guide and ship it
with every release, and I remember having seen Robert Kaiser and Tashi
changes to the wiki page on MozillaTranslator. It still needs a
refresh, but it shouldn't be too difficult to keep up to date. Other
tools users can manage to do the same.
We can also think of locating the outdated content, update and put it
into the wiki, and make sure that the old one gets removed so no
confussion can arise.
>
> Accesskeys are hard, and can't really be automated across the board. At
> least for complex script languages like Japanese or Chinese, there are
> no good accesskeys, which is likely why the current system is, well,
> really flexible.
>
I don't expect MT auto-assigning accesskeys; the best assignment can
only be done by humans, IMHO. But any tool could be smart enough,
given clear rules in l10n files, to tell if two labels have the same
letter, and to list remaining available letters, sorting them so the
best ones by its typeface are first in that list.
> How does our code get to accesskeys? Does someone have a pointer to the
> source that actually gets those from the doc? I have another testing
> extension in the queue, which goes over parts of our UI, and I might be
> able to add a testing step for accesskeys, if I find out what I need to
> replicate.
I must be forgetting something obvious, because I think it's pretty
simple most part of the time, at least for XUL and DTDs: the XUL file
invokes one or more DTDs, like in:
http://lxr.mozilla.org/mozilla/source/toolkit/content/customizeCharset.xul#43
and then uses entities defined in that DTD, like in:
http://lxr.mozilla.org/mozilla/source/toolkit/content/customizeCharset.xul#73
which uses &add.accessKey; defined in customizeCharset.dtd:
http://lxr.mozilla.org/mozilla/source/toolkit/locales/en-US/chrome/global/customizeCharset.dtd#46
What happens when two or more DTDs define the same entity is beyond my
knowledge; I find sensible that the latter DTD loaded prevails, but I
can't confirm it.
Parsing the XUL file should be enough to tell which letters are being
used, for which labels (button labels, menu items, etc.), and
therefore which accesskeys use a letter not present in the label (this
is already done by L10n tool checks). It would also allow to tell
duplicate letters for accesskeys (and this can't be done by L10n
tools, which only have access to L10n files, not XUL).
But, surely, you already know this and are asking for something else I
can't even see. :-)
>
> My testing stuff focuses on testing as part of the build process, which
> may just be because that's something I can control.
>
Testing at build time is definitely a MUST, but testing at localizing
time would a be a good thing, IMHO. It's like webapp forms checking:
checking values at server is a MUST, but JavaScript testing saves
cycles, bandwith and provides better user experience.
>> Autotranslate is of course something desirable, but it's somewhat
>> complex to add it to MT because of its current design model (with MT,
>> everything is loaded to RAM, which uses a LOT, but that doesn't mean
>> that searches for auto-translation are going to be quick). Also, I'm
>> already late in my schedule for my own replacement for MT, which will
>> be my final year project and should include all of this and other
>> features.
>
> What would autotranslate do?
It should provided automated translation of strings when they appear
twice or more times and, in the past, they have been translated always
in the same way. For instance, auto-translating "Preview..." to
"Previsualizar...", at least in spanish, would be a bad idea, because
we translate to several words. However, auto-translating "Bookmark
This Link..." to "Añadir este enlace a marcadores..." will always be fine.
For longer strings, like "Automatically perform the associated Action
with each of the following file types:", it not only would save
typing, but would ensure a more consistent translation.
(BTW, the above examples are real, and actually come from a MT QA
query that lists strings with the same original text that have been
translated in diverging ways).
>
> Thanks for the input
>
Thank you for your efforts.
Axel Hecht
> Axel Hecht escribió:
>> Ricardo Palomares Martinez wrote:
>>> Since I'm quitting from Firefox 3.0 l10n for es-ES and Andres is
>>> actually gone for a while, (...)
>> Anything in particular that makes you quit? I'd be happy to get a mail
>> on this, too.
>
>
> Not that I mind to make the reasons public, but I think that would be
> going off-topic, so I'll answer you by e-mail.
>
Thanks
>
>> I got scared yesterday. I tried to find the localization team list and
>> failed. I need to whack that page with a hammer.
>
> :-)
>
>> Then again, it's a wiki, and everybody else could do that, too.
>>
>
>
> I would be scared to update the L10n main page without having been
> told to do so. :-)
>
I'll do some whacking any time soon.
It seems to be a tad more tricky. I did some testing and peeking, and in
the main browser menu, at least the accesskey 'C' is given out at least
twice. The difference is, it needs to be displayed, and there is frame
construction foo in the middle of it.
I posted to .layout to get some additional opinions on this, hopefully
there is a simpler way to check.
See
http://lxr.mozilla.org/seamonkey/source/browser/locales/en-US/chrome/browser/browser.dtd
with accesskeys "C" and
http://groups.google.com/group/mozilla.dev.tech.layout/browse_frm/thread/43d96e44001156dd/ae0df6a493dfea04#ae0df6a493dfea04.
I'm working on using some of the architecture I did for CompareLocales
to check for reoccurring words and to put those into some kind of
database to use for a glossary. If there are actually phrases, that'd be
an interesting enhancement there. I'll try to not make my stuff block that.
Axel
Cédric Corazza
> I'm working on using some of the architecture I did for CompareLocales
> to check for reoccurring words and to put those into some kind of
> database to use for a glossary. If there are actually phrases, that'd be
> an interesting enhancement there. I'll try to not make my stuff block that.
We (fr team) actually use (and I guess other l10 teams do) a glossary.
May be it doesn't worth the pain for you to spare time on this, unless
other teams want this kind of tool. If you would end with building that
tool, please, don't make it mandatory to pass some kind of l10n review
to get approval before shipping for instance. Certain terms could be
translated differently according to the context.
It comes to my mind 'add-ons' we translated two different ways, or
'phishing' we translated three different ways according where we found
these terms. There are other ones, but it would be a litany :-) .
Regards
Axel Hecht
Is this an issue of grammar? I'd find it confusing that phishing would
be three different things, for example.
(And no, I don't expect to include the glossary into testing.)
Axel
Cédric Corazza
> Is this an issue of grammar? I'd find it confusing that phishing would
> be three different things, for example.
No. It's rather because this word is new and doesn't ring the bell for
Web newcomers. The French official recommendation is 'hameçonnage' which
doesn't ring the bell too (except maybe for French Canadian people). We
also used 'contrefaçon' which means 'counterfeiting' or 'forgery'. And
last, we also kept 'phishing' as is for advanced users. So we mixed all
these terms so that everyone know what this is about.
For 'add-ons' we chose 'Modules complémentaires' meaning 'Additionnal
modules' or simply 'modules', cause it sounds weird to use the 'long
translation' everywhere'. And so on...
Cédric
Axel Hecht
> Axel Hecht a écrit :
>> Is this an issue of grammar? I'd find it confusing that phishing would
>> be three different things, for example.
>
> No. It's rather because this word is new and doesn't ring the bell for
> Web newcomers. The French official recommendation is 'hameçonnage' which
> doesn't ring the bell too (except maybe for French Canadian people). We
> also used 'contrefaçon' which means 'counterfeiting' or 'forgery'. And
> last, we also kept 'phishing' as is for advanced users. So we mixed all
> these terms so that everyone know what this is about.
This part of the thread gets a little off-topic, I'm having the feeling
that using different terms at different places might be confusing people
more than pulling them in.
Don't get me wrong, it's up to you, but I suggest revisiting that
decision. You know, we're only at 20% in France ;-), but we still may be
able to just coin a term. And I'd be curious what google uses, might be
good to pick the same term at least where we're tying in to their service.
> For 'add-ons' we chose 'Modules complémentaires' meaning 'Additionnal
> modules' or simply 'modules', cause it sounds weird to use the 'long
> translation' everywhere'. And so on...
Yeah, this sounds like something that might happen in quite a few
languages. Almost nothing is as short as English, so it may be good to
use parts of terms at places where it's not ambiguous.
Note to self, make the translated strings a list.
Axel
Robert Kaiser
> Great points throughout, it may actually be interesting to put some
> ideas on different hooks, in particular the automated tests should
> really be run by the build infrastructure.
It's hard to automatically test if the strings look to be displayed
correctly and in the right language, that's why this idea of a simple
test-feedback mechanism came to my mind.
>> Additionally, a fallback solution at least at build time so that
>> non-full localizations can be filled up to build full locales could
>> improve some processes, as such a mechanism would not only make it
>> harder to break builds with new strings, but also could be leveraged
>> for doing locales that only change parts of a different existing
>> locale (think en-US -> en-GB -> en-[CA|AU] and similar ones).
>
> I somehow get the impression that content packs would be good to have.
I think we actually could need something a bit different than what we
had thought as "content packs" in the past. Those were a
marketing-driven failure back then, actually.
I think we need some locale fallback mechanism to override certain parts
of a locale - either on the runtime or even only the build-time side.
Robert Kaiser
Cédric Corazza
> This part of the thread gets a little off-topic, I'm having the feeling
> that using different terms at different places might be confusing people
> more than pulling them in.
> Don't get me wrong, it's up to you, but I suggest revisiting that
> decision. You know, we're only at 20% in France ;-), but we still may be
> able to just coin a term. And I'd be curious what google uses, might be
> good to pick the same term at least where we're tying in to their service.
You're right, we had a discussion about that among the team, but
newspapers and magazines use all these terms. I guess we will stick to
'contrefaçon' (forgery) for FF 3, which term is not ambiguous.
I thought about something which could be very useful for l10n teams (and
even for en-US locale too, but maybe these pages tests are drown in
Litmus :-) ).
I'm currently trying to put the 'verified1.8.1.1' tag on the fr bug, and
I can't find a web page which shows me the message I'm looking for.
As you said in your previous post, a list of all strings should be useful.
Let's imagine a web page with some strings whose anchors bring us to a
simple web test page that make appear the string we are looking for.
I'm aware that this won't be possible for the at least 11000 strings for
Fx/toolkit, but most of them are easily reachable through the Fx UI.
I'm thinking about these tricky strings that are hard to find.
Well, it's not very clear in my mind how to set this up, and everyone
could contribute to set up this. The l10n bug feedback we have after a
release are often about these 'unaccessible' strings that are randomly
reached in particuliar circumstances.
Well, it's just an idea.
btw the way, the string I was looking for was 'insdel-sec.label' in
'metaData.dtd'.
Cédric
Ricardo Palomares Martinez
>
> It seems to be a tad more tricky. I did some testing and peeking, and in
> the main browser menu, at least the accesskey 'C' is given out at least
> twice. The difference is, it needs to be displayed, and there is frame
> construction foo in the middle of it.
Sorry, I don't really understand the last sentence. "C" is used as an
accesskey several times in the main browser menu, but I haven't seen
those accesskeys conflicting because they are in different drop-down
menus, namely:
<!ENTITY errorConsoleCmd.accesskey "C"> (Tools menu)
<!ENTITY copyCmd.accesskey "C"> (Edit menu)
<!ENTITY viewCustomizeToolbar.accesskey "C"> (View menu)
<!ENTITY copyLinkCmd.accesskey "C"> (context menu)
<!ENTITY closeCmd.accesskey "C"> (File menu)
And that's all. What I dream of is a way to make clear in the DTD (so
parsing XUL was not needed) that errorConsoleCmd.accesskey belongs to
Tools menu, copyCmd.accesskey belongs to Edit menu, and so. Even
simpler, the tool doesn't really care if the menu is Tools, File or
whatever. I would be happy if it can tell that all entities starting
by "fm" make an single UI unit in which accesskeys can conflict, "vtm"
is other (View menu / Toolbars submenu) and so.
But I realize that's a lot of work that introduces risk in code (so
many changes in entity names) and gives little value to en-US.
> I'm working on using some of the architecture I did for CompareLocales
> to check for reoccurring words and to put those into some kind of
> database to use for a glossary. If there are actually phrases, that'd be
> an interesting enhancement there. I'll try to not make my stuff block that.
Actually, as Cédric says, terms can be translated differently
according to context, and that's more likely to happen in single,
isolated words than in whole sentences (and there are a LOT of
reocurring sentences in the 12,000+ strings of SeaMonkey, for instance).
Axel Hecht
> Axel Hecht a écrit :
>> This part of the thread gets a little off-topic, I'm having the
>> feeling that using different terms at different places might be
>> confusing people more than pulling them in.
>> Don't get me wrong, it's up to you, but I suggest revisiting that
>> decision. You know, we're only at 20% in France ;-), but we still may
>> be able to just coin a term. And I'd be curious what google uses,
>> might be good to pick the same term at least where we're tying in to
>> their service.
>
> You're right, we had a discussion about that among the team, but
> newspapers and magazines use all these terms. I guess we will stick to
> 'contrefaçon' (forgery) for FF 3, which term is not ambiguous.
>
> I thought about something which could be very useful for l10n teams (and
> even for en-US locale too, but maybe these pages tests are drown in
> Litmus :-) ).
> I'm currently trying to put the 'verified1.8.1.1' tag on the fr bug, and
> I can't find a web page which shows me the message I'm looking for.
I think you found out by now, but it's a keyword.
> As you said in your previous post, a list of all strings should be useful.
> Let's imagine a web page with some strings whose anchors bring us to a
> simple web test page that make appear the string we are looking for.
> I'm aware that this won't be possible for the at least 11000 strings for
> Fx/toolkit, but most of them are easily reachable through the Fx UI.
> I'm thinking about these tricky strings that are hard to find.
> Well, it's not very clear in my mind how to set this up, and everyone
> could contribute to set up this. The l10n bug feedback we have after a
> release are often about these 'unaccessible' strings that are randomly
> reached in particuliar circumstances.
> Well, it's just an idea.
> btw the way, the string I was looking for was 'insdel-sec.label' in
> 'metaData.dtd'.
>
Not exactly sure what you're saying here. The closest in my mind would
be that a user says "you have a typo in the string "Proprietes des
elements", in which case you could use lxr's full text search, like
http://lxr.mozilla.org/l10n-mozilla1.8/search?string=Propri%C3%A9t%C3%A9s+des+%C3%A9l%C3%A9ments
It does have the culprit that it doesn't really search only one
language, so it may give too many results.
I'm really not sure if that's what you meant, though.
Axel
Giacomo Magnini
> An hour per day for six months? That's ridiculous.
Some examples from it-IT experience follow.
FF: Keeping up to date with trunk development is hopeless (eg., Places
added and then removed), so our FF main translator will hack the
translation just after the freeze has happened.
This will take from a night to three days depeding on pressure and time
contraints, modulo late checkins (eg., prefs rewrite). The other guy
helping with the docs usually can't even start sice the docs are totally
missing, or still waiting for an alignment with the late UI changes.
This means that the docs translation will start only *after* UI
translation is complete and/or when updated docs are available (well
after string freeze).
TB: The app has maybe twice the strings of FF and much less
users/testers. Staying up to date with development is impossible as
well, since the major new features of the app usually land very near the
freeze date and are subject to change till the very last minute.
Thanks God there are no docs for the time being, since the guy in charge
is already taking a *few days off* his own job to finish up translation
before major releases...
SM (my own experience): I'm in charge of everything but localized
installers and .zip's. This means keeping up to date the translation of
all of the strings of FF, TB, CZ, DOMI and Venkman all of the time all
by myself, plus dealing with around 1MB of translated help docs. Oh,
don't forget to add translated start pages...
SB/Calendar: I'll ask the guy in charge to report his own experience
here, but it wasn't much better than the others, probably very similar
to the FF one.
We are talking about translators working on the product since their very
first versions, so it's not a matter of unexperience.
Please don't forget that real life and college and jobs usually impact
on the free time devoted to localizing. Can you imagine how easy string
freezes and/or major releases often coincide with major milestones in
real life? ;) Murphy rules.
Add to the usual tasks also staying up to date with newsgroups,
admin/mod a forum with 12K users begging for help and a few other things
here and there (interviews, patch for bugs, additions to web site and
forum, etc.).
So, one hour a day for six months may be too much, but is not that far off.
> Is that due to some requirement we have that a particular localisation
> should always be building? If so, that seems silly to me. Why should a
> localisation team not take a weekend once a month to catch up, during
> the normal development cycle? OK, so more time is needed near releases,
> but surely there's no reason for teams to have to update and build from
> CVS, check tinderboxes, etc. every _day_?
Doing a catchup once in a while is usually worthless: if you are lucky
you will get a few days worth of good builds to test. On average, you'll
get one or two builds ok: in the worst case, not even a single good
build (changed strings in the meantime, underestimated
difficulty/length, your own errors, etc.). Has been tried before, and
has been turned into trying to catch up when a milestone nears and doing
some bursts of work (even if not covering all of the strings), so that
helps keeping the amount of untranslated strings to a somewhat
reasonable level (a hundred or less, depending on the app: for SM,
usually a new version of CZ will mean around 100 strings to check,
modify or translate ex novo).
Hope this gives some insight on the translators work.
Suggestions for the future:
===========================
I fully agree with Kairo's posts, and add my own two cents here.
1) If XUL Runner based apps are the future, XR strings should be common
to all of the apps and not replicated everywhere (eg., avoid duplicated
ff/tb/sm strings in different trees, or toolkit). This will help testing
locales, dividing all of the strings in units/modules that can be
checked only when needed (that is, when something really changes in
them, so you/we don't end up retesting the same things over and over).
This will also greatly help in having coherent translations among apps
for the same locale.
"Divide et impera" could be a nice thing to selectively test only what
is really needed.
2) While I can understand the need for checking as much as possible in
house the translation, try to delegate as much work as possible. For
example, set one translator of every group (QA contact maybe? Whoever)
to strictly check the adherence of the translation to enforced
guidelines (wrt to links, content, whatever you rule on), so some burden
is offloaded from MoCo personnel.
Hope this helps.
Ciao, Giacomo.
Cédric Corazza
> I'm really not sure if that's what you meant, though.
Hum : I've been fuzzy in my explanations, again :-) .
What I meant was not to search the string in the Firefox files, a lxr
search or a local grep is quite efficient for that.
Let's say a string is in a popup window, and I want to see that string
in context, so I have to search on the Web to find a page that reaches
the requirements to make that popup appears. Sometimes, it is not easy
at all to find pages for particular error messages, alert messages, etc.
That's why I was thinking about simple html test pages that meet the
requirements to make a particular string to be displayed in context.
Well, this would be unneeded for all the strings but only for those that
are hard to make appear in Firefox. That's why I thought about linking
.dtd or .properties entities on a Web page to those test pages that
would make appear them in context. This would improve the l10n QA also.
I hope this was clearer.
Cédric
Axel Hecht
I think that drivers are increasingly aware of this. The sad point is,
Mozilla is such an creative environment that each release something else
just manages to totally blow.
> Add to the usual tasks also staying up to date with newsgroups,
> admin/mod a forum with 12K users begging for help and a few other things
> here and there (interviews, patch for bugs, additions to web site and
> forum, etc.).
> So, one hour a day for six months may be too much, but is not that far off.
>
>> Is that due to some requirement we have that a particular localisation
>> should always be building? If so, that seems silly to me. Why should a
>> localisation team not take a weekend once a month to catch up, during
>> the normal development cycle? OK, so more time is needed near
>> releases, but surely there's no reason for teams to have to update and
>> build from CVS, check tinderboxes, etc. every _day_?
>
> Doing a catchup once in a while is usually worthless: if you are lucky
> you will get a few days worth of good builds to test. On average, you'll
> get one or two builds ok: in the worst case, not even a single good
> build (changed strings in the meantime, underestimated
> difficulty/length, your own errors, etc.). Has been tried before, and
> has been turned into trying to catch up when a milestone nears and doing
> some bursts of work (even if not covering all of the strings), so that
> helps keeping the amount of untranslated strings to a somewhat
> reasonable level (a hundred or less, depending on the app: for SM,
> usually a new version of CZ will mean around 100 strings to check,
> modify or translate ex novo).
I think places is a 'perfect' example that writing localizable code
doesn't stop at putting files into locales/en-US, the first cycles of
the nsis installer, too.
I'm not exactly sure on how to do it, but I should probably get some of
the core hackers together and talk about how to implement new features
in an l10n friendly way. One idea I have would be to suggest to put the
dtd and property files into content for the early stages of development,
and then to move them over into locales/en-US once they're somewhat
stable, and the UI had the first few rounds of iterations.
> Hope this gives some insight on the translators work.
>
> Suggestions for the future:
> ===========================
> I fully agree with Kairo's posts, and add my own two cents here.
>
> 1) If XUL Runner based apps are the future, XR strings should be common
> to all of the apps and not replicated everywhere (eg., avoid duplicated
> ff/tb/sm strings in different trees, or toolkit). This will help testing
> locales, dividing all of the strings in units/modules that can be
> checked only when needed (that is, when something really changes in
> them, so you/we don't end up retesting the same things over and over).
> This will also greatly help in having coherent translations among apps
> for the same locale.
> "Divide et impera" could be a nice thing to selectively test only what
> is really needed.
Sharing strings is a dangerous topic, I'm not sure if we actually did
assess the pitfalls there enough so far.
Think about the phishing story elsewhere in this thread, or odd out
languages. Something like "Open File", could that depend on the gender
of the application name? One wouldn't think so, but I'm not feeling good
about ruling it out. Basically, whenever someone shares a string,
there's a language that goes odd. Maybe not really 100%, but I still
feel that that could happen.
That's why I'm more feeling like putting an emphasis on glossaries, and
not just per language, but across all languages and projects, so that
teams starting with a localization could actually find out which strings
should have a common translation throughout, and to be able to point the
finger at places where it differs. Not necessarily filing a bug on that,
but I think it's worth pointing a finger at it.
> 2) While I can understand the need for checking as much as possible in
> house the translation, try to delegate as much work as possible. For
> example, set one translator of every group (QA contact maybe? Whoever)
> to strictly check the adherence of the translation to enforced
> guidelines (wrt to links, content, whatever you rule on), so some burden
> is offloaded from MoCo personnel.
I, and Tim, agree that we need to get a better idea on spot testing on
the one hand, and on finding out how to incorporate independent external
QA resources into the process.
One thing that seems to happen is that people are used to the odd spots
in their locale for years, in some parts. At least I would be surprised
if that didn't happen. So when checking on the quality of a
localization, having a new and independent set of eyes is really worth a
lot.
This is particularly hard for "niche"-locales. For the big locales, I
don't see a problem, those have lots of users, and a strong community.
Reading through the german fx forum for example, I always see them
pre-announcing alphas and betas and RCs and such, with probably dozens
of users downloading B2 RC1. However odd a string might be, there's a
good chance that someone will see it.
For smaller locales though, getting good testing coverage seems to be
hard. It was for Firefox 2, at least. I'm curious on how to communicate
better what testing should be done, and when. And I'll be hacking more
extensions like https://bugzilla.mozilla.org/show_bug.cgi?id=358740.
Axel
Philip Chee
>> http://translate.songbirdnest.com/
Has anybody looked at BabelZilla's online web translation system?
I've put my extension on that system and translators can work on it
online and|or download and work offline.
<http://www.babelzilla.org/index.php?option=com_wts&Itemid=88&extension=1001&type=lang>
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]I've got a mind like a... a... what's that thing called?
* TagZilla 0.059
J. Paul Reed
> So to start the discussion, it'd be a good idea to collect how much one
> locale of the 40 currently 'costs'. How much time is spent on a locale
> day-to-day (tinderbox build times come to mind), and how much man power
> and computing resources do we need for a release? How much for an
> update, how much for a major new release? I would hope to get
> guestimates or number from folks like localizers, drivers, build, QA, BD
> and product.
On the build side, I think we scale fairly well in the face of locales.
For instance, the cost of supporting 40 locales is not significantly
greater than the cost of supporting 30 locales. The cost of supporting
one or two more locales is basically noise.
This is mostly because the build-side processes we have are designed to
handle multiple locale, so once you have 10 or so, then adding more
isn't that painful. Then it becomes a matter of computing space and power.
I could see life becoming interesting with 100 locales (the official
build run for locales might starting taking overnight, for instance, as
well as update generation), but nothing immediately comes to mind in the
build process that would require radical retooling that isn't a "more
hard drives/more computer power" problem. (Famous last words, I know.)
The one are that I think we could work on that would help the Build side
would be how we handle/coordinate l10n code-freezes and tree closings
during the release process to get builds. We always seem to schedule
these as an afterthought, and we should really try to coordinate that up
front, and begin to use the same sort of processes we use for regular
development (specifically around code freeze/tree closures).
Having said that, I know we've been working through those issues for the
maintenance releases, and 2.0 has some hiccups, but was relatively
smooth, so I think we're moving towards goodness in that area.
Later,
preed
--
J. Paul Reed
Build/Release Engineer - The Mozilla Corporation
smtp://pr...@mozilla.com
irc://irc.mozilla.org/preed
pots://650.903.0800/x256
Gervase Markham
> Sharing strings is a dangerous topic, I'm not sure if we actually did
> assess the pitfalls there enough so far.
Perhaps the right approach is to have a system where you can mark
particular strings or groups of strings in CVS as "equivalent", and
there's a syncing tool which syncs them up. Then each locale can
evaluate each group, and say either "Yes, these will always be the same
for us - let's run the syncing tool regularly" or "No, this won't work
for us for whatever reason - we have to do this group manually".
Gerv
Gervase Markham
Robert Kaiser
> Sharing strings is a dangerous topic, I'm not sure if we actually did
> assess the pitfalls there enough so far.
Yes, there are even different views among people of the same language,
esp. when it comes to either using the original word as an IT jargon
name or translating it to some in practice almost unused but local
language word.
This affects many words, from "link" and "attachment" via "browser" and
"mail" to "phishing" and "plugins". Thos may not only be handled
differently between languages but also between groups of localizers for
the same language. Sometimes it's hard to come to a good conclusion on
those.
There are even some different measures of what people think to be "L10n
quality" ;-)
Robert Kaiser
Giacomo Magnini
> Yes, there are even different views among people of the same language,
> esp. when it comes to either using the original word as an IT jargon
> name or translating it to some in practice almost unused but local
> language word.
While this is very true, we solved this by using a mailing list where
every option is discussed and (to some extent) voted upon. Final
decision will be then added to a "quick dictionary" of common
translations, so that everybody can take advantage of it.
The mailing list is for localizers and for many simple users as well: we
are very lucky that among those users there are also at least 2
professional translators lurking that give their advice on the more
debated matters.
BTW, the prefessional freelance translators' world is very active and
very cooperative with a few OSS projects (eg., OmegaT, on SF.net), so I
would suggest that opening a link there would have some benefits and
give some insight on a matter they know pretty well, especially
regarding glossaries and related technologies.
A good starting point is Sabine, I guess: http://www.wordsandmore.it/
Ciao, Giacomo.
Axel Hecht
I guess we should start with something like coverage how-to.
NetError pages may be one example of hard to expose UI. I just found out
that if you disable javascript and then use DOMI to unhide the one
container, you can see all titles and errors at once. Somewhat funky,
but it works and may actually be valuable. I wonder if I should make my
coverage tool do that.
Are there other odd parts?
Axel