> > Mozilla.org will need its own i18n UI text freeze.
>
> Only if releasing major localizations at the same time with the U.S.
> English version is considered a requirement. Does it really have to be a
> requirement?
I think we should certainly try very hard to make it happen. And,
envisaging what the 1.0 endgame will be like, it shouldn't be too much
difficulty, it just requires organisation.
> Localization freezes make last-minute UI work more difficult.
> Alternatively the release of the U.S. English version could function as
> the freeze in which case localization would be published a little later.
It would be a shame to have to do this. The release of 1.0 is inevitably
going to be accompanied by quite a lot of publicity (not generated by us)
and so if people head over here and find it's only available in US
English, that would be a shame.
How about this for a plan:
- From a given date during the 1.0 "freeze", say approx. 2 weeks before
the expected release date, we say "Please try and avoid making sweeping UI
string changes, and all changes you do make must now be posted in
n.p.m.l10n." Localisers can then start localisation based on the builds
from that date, and track late changes using the newsgroup.
- 3 days (?) before the release (and we should be able to guess roughly
when that is) we implement a total freeze, and tell the l10n guys, who
have been tracking the posted changes, to update, check and polish and get
XPIs ready.
This strikes a fair balance between moving the targets and keeping the
flexibility. If some langpacks don't make it for a few days after the
release, fair enough. But, if everyone knows this is going to happen, they
can set aside time and plan around it.
Gerv
