moz2, hg, and l10n
Axel Hecht
I too joined a moz2 call for the first time in a while, and as most
other folks, am still confused about how things go forward.
Whichever, mozilla-central will go live, and I wonder how we want to do
l10n work against those.
Any suggestions? On either solution or timeline to find one?
Axel
Benjamin Smedberg
Sounds like the simplest solution is to continue using CVS for localization
until things like access controls are figured out: I think we should write a
simple script which can be used to check out l10n after you've pulled the
main tree:
checkout-l10n.py fr pt
or
checkout-l10n.py all
I guess this would mean we'd need to branch l10n-cvs.
--BDS
Axel Hecht
I don't see another way either. I'd start with an empty list of locales
this time around, though, and only branch those that want to.
Which implies that I'd prefer to leave gecko 1.9.0.x on trunk and branch
for MOZILLA_CENTRAL_L10N_BRANCH or something.
Other things on my mind, beyond access control:
- can we have an "en-US only" repo?
- should we have a repo per locale?
- what should we do with tb l10n?
Axel
Robert Kaiser
> Which implies that I'd prefer to leave gecko 1.9.0.x on trunk and branch
> for MOZILLA_CENTRAL_L10N_BRANCH or something.
Ugh. trunk not being trunk sounds a bit strange to me at least, I guess
it won't be easier for localizers.
Robert Kaiser
Mike Connor
isn't a huge overhead for just the locale, and the shared locale bits are a
major part of it, and shouldn't diverge between apps, IMO. Localizers get a
single repo to track, pull, anrd update, and we can reuse build scripts
between apps.
- Mike
----- Original Message -----
From: dev-planni...@lists.mozilla.org
<dev-planni...@lists.mozilla.org>
To: dev-pl...@lists.mozilla.org <dev-pl...@lists.mozilla.org>
Sent: Thu May 15 16:08:51 2008
Subject: Re: moz2, hg, and l10n
Axel Hecht wrote:
>I don't see another way either. I'd start with an empty list of locales
>this time around, though, and only branch those that want to.
>
>Which implies that I'd prefer to leave gecko 1.9.0.x on trunk and branch
>for MOZILLA_CENTRAL_L10N_BRANCH or something.
>
>Other things on my mind, beyond access control:
>
>- can we have an "en-US only" repo?
>- should we have a repo per locale?
>- what should we do with tb l10n?
Add to that Calendar and Suite l10n. Please don't make it harder and more
confusing to people to localize our products (e.g. by needing to pull
different repos and push to them).
This will surely hurt the localization efforts of the smaller products
much more, as our teams are much smaller (mostly just one person) than
the Firefox l10n teams.
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
Axel Hecht
I'd consider the l10n-for-central-in-cvs to be a temporary measure, and
something to be fixed well before we get close to release. Only a few
teams will eagerly follow the development, I guess, like the French and
the Polish folks. I'm happy to punt those on a branch, if we have to.
On the other hand, I expect to take new localizations for Firefox 3.0.x
for a significant time, and I want those to work on a simple setup, and
that'd be trunk. Same goes for smaller localization teams that want to
update their localization of 3.0.x, too.
I see a learning curve coming up for us here, like for everybody else in
the Mozilla ecosystem, and I hope that I get the techy bigger teams to
pave the way for the smaller ones. Similar to what happens now on the
main dev tree.
Axel
Peter Weilbacher
> Robert Kaiser wrote:
>> Axel Hecht wrote:
>>> Which implies that I'd prefer to leave gecko 1.9.0.x on trunk and branch
>>> for MOZILLA_CENTRAL_L10N_BRANCH or something.
>>
>> Ugh. trunk not being trunk sounds a bit strange to me at least, I guess
>> it won't be easier for localizers.
>
> I'd consider the l10n-for-central-in-cvs
Is it just me or have other people trouble following Mercurial threads, too?
I have been a contributor to the Mozilla project for several years now but
most of the posts on hg are riddled with with weird names and very few seem
to state something definite. In conjuction the different designations for
upcoming versions that makes it very confusing for someone who just contributes
in his spare time.
Peter.
Axel Hecht
> I think for l10n, one repo per locale seems to make the most sense. There
> isn't a huge overhead for just the locale, and the shared locale bits are a
> major part of it, and shouldn't diverge between apps, IMO. Localizers get a
> single repo to track, pull, anrd update, and we can reuse build scripts
> between apps.
That would allow localizers to just pull their own locale only, yeah.
Anyone with ideas how we would replicate things like the Firefox3Frozen
bonsai query, spanning a given set of locales and only some directories?
I'd probably want some aggregated pushlog, too, to do l10n builds "on
land", as joduinn calls that. Otherwise I'd have to punt on 60+
different pushlogs all the time, that sounds horrible.
Axel
Simon Paquet
>> I'd consider the l10n-for-central-in-cvs
>
> Is it just me or have other people trouble following Mercurial
> threads, too?
No (it's not just you) and yes (people like me) have trouble following
hg threads as well.
Robert Kaiser
> Robert Kaiser wrote:
>> Axel Hecht wrote:
>>> Which implies that I'd prefer to leave gecko 1.9.0.x on trunk and branch
>>> for MOZILLA_CENTRAL_L10N_BRANCH or something.
>>
>> Ugh. trunk not being trunk sounds a bit strange to me at least, I
>> guess it won't be easier for localizers.
>
> I'd consider the l10n-for-central-in-cvs to be a temporary measure, and
> something to be fixed well before we get close to release. Only a few
> teams will eagerly follow the development, I guess, like the French and
> the Polish folks. I'm happy to punt those on a branch, if we have to.
Count in German to those who follow closely ;-)
If we are sure it will be temporary (until we switch to DVCS
schematics), I think we could live with doing branch, even if it feels
quite unnatural, but given the /l10n trunk will match the /cvsroot trunk
in that intermediate timeframe, I guess it's reasonable.
Robert Kaiser
Axel Hecht
Given how soon we're going to start shipping 3.1 alphas, I don't think
there's any time for going for intermediate cvs-branch-based concept.
Here is my list of requirements for l10n on hg, others should add theirs:
For localization:
- localizers need write access to hg.m.o.
- We need hg repo(s) for Firefox 3.1 localizations, with imports from cvs
- compare-locales support (*)
For release management:
- I need mxr spanning all 3.1 localizations
- I need a pushlog with file information, committer, and comment
spanning all 3.1 localizations, both human readable and machine
readable, with at least time span given.
For builds:
- EXPAND_LOCALE_SRCDIR needs to at least resolve to where the l10n repos
end up, http://mxr.mozilla.org/mozilla-central/source/config/config.mk#892
Others?
(*) On CVS, compare-locales uses
make -f client.mk echo-variable-LOCALES_browser
We probably want something simpler, and it should be extendable to other
non-central apps.