l10n, mozilla-central, and mercurial (hg)

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

l10n, mozilla-central, and mercurial (hg)

Axel Hecht
Hi all,

I'd like to open a discussion on migrating our localizations over from
cvs to mercurial for firefox.next.

Without going into too much detail of VCS fights, I think there are a
few advantages to that:

- Integration with the rest of the Mozilla ecosystem
- More flexibility in how to work on localization, if you want to
- More power to tools

There are a few down-sides:

- Ouch, yet another tool
- Mercurial can be confusing, with all the check-in vs push and that


Going forward, I don't think that mercurial is going to be more
challenging than cvs for new localizers. It's gonna be different to
something they don't know ;-).
For our existing localizers, it's going to depend on how much complexity
you want to see. You can use hg like cvs, if you just ignore local
commits and do a (commit;push) whenever you would have done a commit
with cvs. For folks that like more power, they can decide for themselves
to look into mercurial clones, or publish their own repos, or stuff like
that.

In the end, if you don't want hg to do anything beyond what cvs could,
it's not harder to do so. It might take discipline to not be tempted to
want more, that's probably the hardest thing.

I do expect the current rush towards mozilla-central to create quite a
few usable documents on how to get the best out of mercurial, too.


For the tools, I do think that having l10n in hg with all the change
history will offer interesting UE paths. A changeset in mercurial has
all the files together, so for those following the development, it
should be possible to localize patch by patch without having to resort
to bonsai queries and such. I would expect it to become easier to move
changes between different tools, too.

Anyway, I'd like to get your comments.

This is all in its early stages, and I myself don't fully know which
repo will go where and all that. I opened a thread on .planning for
that, and filed bug 433846.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Hasse-2
In article <[hidden email]>, Axel Hecht
wrote...
> Hi all,
>
> I'd like to open a discussion on migrating our localizations over from
> cvs to mercurial for firefox.next.

I have no experience with mercurial, but have read that it is not
possible to checkout and update only selected directories. Is that
right?

Not being able to only checkout the en-US language files is a big
drawback for me.

--
Hasse
sv-SE l10n team
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Axel Hecht
Hasse wrote:

> In article <[hidden email]>, Axel Hecht
> wrote...
>> Hi all,
>>
>> I'd like to open a discussion on migrating our localizations over from
>> cvs to mercurial for firefox.next.
>
> I have no experience with mercurial, but have read that it is not
> possible to checkout and update only selected directories. Is that
> right?
>
> Not being able to only checkout the en-US language files is a big
> drawback for me.
>

Yeah, that is among the topics that I raised in .planning. Note, being
able to pull en-US is independent of what we do for l10n, really. It
merely depends on what en-US is doing, and they're doing hg.

I hope that we'll be able to create a fake rep for just the stuff that
localizers need. But then, I have no clue how to handle thunderbird in
that picture and more. Feel free to comment in .planning on those things.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Simon Paquet-3
In reply to this post by Axel Hecht
Axel Hecht wrote:

>Hi all,
>
>I'd like to open a discussion on migrating our localizations over from
>cvs to mercurial for firefox.next.
>
>Without going into too much detail of VCS fights, I think there are a
>few advantages to that:
>
>- Integration with the rest of the Mozilla ecosystem
>- More flexibility in how to work on localization, if you want to
>- More power to tools
>
>There are a few down-sides:
>
>- Ouch, yet another tool
>- Mercurial can be confusing, with all the check-in vs push and that

Personally I don't see a real need for localizers to move over to
Mercurial. Most of its advantages (e.g. better merge functionality,
better and easier branch functionality, fully distributed development) is
of no use or only of minor use in the localization community as far as I
can see.

Most localization teams consist of only 1-3 people, the larger teams (IRC
French or Japanese) can probably be counted with one hand, so a fully
distributed development model has no real advantages over a centralized
model as in CVS. Same goes for merging and branching, which are really a
non-issue for localizations IMO.

So with only minor advantages, the "Ouch, yet another tool" issue becomes
a real dealbreaker IMO, given that it has taken quite some time for many
localizers to become acquainted with CVS and its ways.

Just my 0.02c
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Justin Wood (Callek)-2
Simon Paquet wrote:

> Axel Hecht wrote:
>
>> Hi all,
>>
>> I'd like to open a discussion on migrating our localizations over from
>> cvs to mercurial for firefox.next.
>>
>> Without going into too much detail of VCS fights, I think there are a
>> few advantages to that:
>>
>> - Integration with the rest of the Mozilla ecosystem
>> - More flexibility in how to work on localization, if you want to
>> - More power to tools
>>
>> There are a few down-sides:
>>
>> - Ouch, yet another tool
>> - Mercurial can be confusing, with all the check-in vs push and that
>
> Personally I don't see a real need for localizers to move over to
> Mercurial. Most of its advantages (e.g. better merge functionality,
> better and easier branch functionality, fully distributed development) is
> of no use or only of minor use in the localization community as far as I
> can see.
>
> Most localization teams consist of only 1-3 people, the larger teams (IRC
> French or Japanese) can probably be counted with one hand, so a fully
> distributed development model has no real advantages over a centralized
> model as in CVS. Same goes for merging and branching, which are really a
> non-issue for localizations IMO.
>
> So with only minor advantages, the "Ouch, yet another tool" issue becomes
> a real dealbreaker IMO, given that it has taken quite some time for many
> localizers to become acquainted with CVS and its ways.

Given that *anyone* wanting to build Firefox (or many other applications
soon), will need to learn at least to some extent Hg, so "yet another
tool" will be applied *anyway* to majority of people (current localizers
included).

And backwards to cvs for new contributors in the future.

So, in my opinion (as a non-localizer) is that Hg could be useful as a
unified VCS for things. [I do agree advanced features of Hg are not
really needed here].

--
~Justin Wood (Callek)
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Simon Paquet-2
Justin Wood (Callek) wrote on 16. May 2008:

> Given that *anyone* wanting to build Firefox (or many other
> applications soon), will need to learn at least to some extent Hg,
> so "yet another tool" will be applied *anyway* to majority of
> people (current localizers included).

Localizers normally do not build the applications themselves, at least
the Calendar localizers that I know don't. Instead they rely on the
tinderboxen for building.

So I don't think that your argument is really valid in this context.

Simon

--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog:     http://weblogs.mozillazine.org/calendar
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Axel Hecht
Simon Paquet wrote:

> Justin Wood (Callek) wrote on 16. May 2008:
>
>> Given that *anyone* wanting to build Firefox (or many other
>> applications soon), will need to learn at least to some extent Hg, so
>> "yet another tool" will be applied *anyway* to majority of people
>> (current localizers included).
>
> Localizers normally do not build the applications themselves, at least
> the Calendar localizers that I know don't. Instead they rely on the
> tinderboxen for building.
>
> So I don't think that your argument is really valid in this context.

They do pull en-US sources, though, right? And those are in hg now. I'd
like to add that at least for Firefox, pulling will obviously become
easier than it currently is, it might even be GUI-able if we ship a GUI
version of hg with MozillaBuild.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Jesper Kristensen-4
In reply to this post by Axel Hecht
Axel Hecht skrev:
> Hi all,
>
> I'd like to open a discussion on migrating our localizations over from
> cvs to mercurial for firefox.next.

I am a website localizer working in svn, so I arguably cannot speak for
product localizers, but I will do that anyway.

I think it would be best to have en-US and locales in the same VCS and
directory structure. Be that cvs or hg.

I have heard a complaint that it is nearly impossible in CVS to share
work on localization when the tree is closed (e.g. for beta release).
Would hg be able to solve that?
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Stefan Plewako
In reply to this post by Axel Hecht
Axel Hecht pisze:
> Simon Paquet wrote:
>> Justin Wood (Callek) wrote on 16. May 2008:
>> Localizers normally do not build the applications themselves, at least
>> the Calendar localizers that I know don't. Instead they rely on the
>> tinderboxen for building.
>>
>> So I don't think that your argument is really valid in this context.
>
> They do pull en-US sources, though, right?

Not necessarily, some use only webtools (like bonsai and mxr) for tracking changes.
CVS checkout is not only way to get sources too..


Stef

--
Aviary.pl l10n team
http://www.aviary.pl
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

flod
In reply to this post by Axel Hecht
Axel Hecht ha scritto:
> They do pull en-US sources, though, right?
Here I am, and I'm also using Mozilla Translator to import strings from
en-US and export them to CVS structure (and I'm wondering if it will be
possible to continue using it).

Francesco.

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Axel Hecht
In reply to this post by Axel Hecht
Francesco Lodolo wrote:
> Axel Hecht ha scritto:
>> They do pull en-US sources, though, right?
> Here I am, and I'm also using Mozilla Translator to import strings from
> en-US and export them to CVS structure (and I'm wondering if it will be
> possible to continue using it).

Can you clarify? I could guess what you saying, but I'd rather not.
"Import strings from en-US" means exactly what?

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Axel Hecht
In reply to this post by Jesper Kristensen-4
Jesper Kristensen wrote:

> Axel Hecht skrev:
>> Hi all,
>>
>> I'd like to open a discussion on migrating our localizations over from
>> cvs to mercurial for firefox.next.
>
> I am a website localizer working in svn, so I arguably cannot speak for
> product localizers, but I will do that anyway.
>
> I think it would be best to have en-US and locales in the same VCS and
> directory structure. Be that cvs or hg.

There'd be two ways to do this, I guess:

Move en-US off the main rep, or move l10n into that. Moving en-US off is
something that I don't see happening, really. Moving l10n into would
require localizers to get contributor access to the main rep, which
would raise the bar of their technical capabilities significantly. Which
is the only reason why we moved them off initially.

I agree that it's a somewhat awkward compromise, but that's the nature
of compromises, I guess.

> I have heard a complaint that it is nearly impossible in CVS to share
> work on localization when the tree is closed (e.g. for beta release).
> Would hg be able to solve that?

Yeah, that sucked for beta, but we have a solution for that problem now.
There is a bonsai query based on cvs modules that only contains the
frozen directories.

hg would be different, and I can't really say how. We wouldn't really
branch in hg, but clone reps. Which isn't really saying a whole lot
about how things would work in times of tree closure for creating builds
and such. I'll re-raise the question in .planning.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

flod
In reply to this post by Axel Hecht
>
> Can you clarify? I could guess what you saying, but I'd rather not.
> "Import strings from en-US" means exactly what?
Probably "import" it's not the most suitable word.

This is the way I've localized Firefox 3 in Italian:

1) I have local directories on my hard-drive that contain the en-US
files taken from CVS: I use TortoiseCVS on Windows and update these
folders simply doing a CVS update.

2) I have several "modules" in Mozilla Translator (toolkit, browser,
security, etc.), each one pointing to the respective en-US folder as a
source and the it-IT folder as a destination. To "import" updated or new
strings I have just to update that module in MT.

3) When localization is finished, I export the updated module (using the
CVS structure) on my local drive.

4) Using TortoiseCVS I commit changes from the it-IT folder.

Francesco

_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Axel Hecht
In reply to this post by Axel Hecht
Francesco Lodolo wrote:

>>
>> Can you clarify? I could guess what you saying, but I'd rather not.
>> "Import strings from en-US" means exactly what?
> Probably "import" it's not the most suitable word.
>
> This is the way I've localized Firefox 3 in Italian:
>
> 1) I have local directories on my hard-drive that contain the en-US
> files taken from CVS: I use TortoiseCVS on Windows and update these
> folders simply doing a CVS update.
>
> 2) I have several "modules" in Mozilla Translator (toolkit, browser,
> security, etc.), each one pointing to the respective en-US folder as a
> source and the it-IT folder as a destination. To "import" updated or new
> strings I have just to update that module in MT.
>
> 3) When localization is finished, I export the updated module (using the
> CVS structure) on my local drive.
>
> 4) Using TortoiseCVS I commit changes from the it-IT folder.
>
> Francesco
>

Ah, ok. So you get the en-US files from cvs allright.

Regarding your original question, I would expect that mozilla translator
continues to work for firefox.next. Worst case would be that it has
hardcoded the top-level names for mozilla and l10n, like many of the
tools I write ;-), that should be easy to fix, though.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Robert Kaiser
In reply to this post by Axel Hecht
Axel Hecht wrote:
> I'd like to open a discussion on migrating our localizations over from
> cvs to mercurial for firefox.next.

I think for L10n communities/groups/people that use it more or less like
CVS (i.e. push for every commit), not much changes other than having to
use a different tool to do the same.

A DVCS can help groups though that want to do reviews inside the group,
as everyone can exchange locally committed changesets within the group.
Additionally, freeze times can be made easier, as people can commit
their changes locally and only push them within the timeframe when we
open the tree.
Also having one repo per language (given we have the glue code to pull
what's needed on build machines or for --enable-ui-language builds) can
help with permissions management, adding new locales, etc - even though
it makes cross-language mass changes harder.

If those assumptions really hold true for hg (I'm judging them from my
private useage of git, mainly), than I think it may be a good idea to
switch some time. (For what I heard, the DVCSes are quite similar, esp.
git/hg.) The switch doesn't necessarily need to be at the same tiome as
development switches to mozilla-central though, as repos are already
decoupled, it's just a question of the glue code.

Robert Kaiser
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Axel Hecht
Robert Kaiser wrote:

> Axel Hecht wrote:
>> I'd like to open a discussion on migrating our localizations over from
>> cvs to mercurial for firefox.next.
>
> I think for L10n communities/groups/people that use it more or less like
> CVS (i.e. push for every commit), not much changes other than having to
> use a different tool to do the same.
>
> A DVCS can help groups though that want to do reviews inside the group,
> as everyone can exchange locally committed changesets within the group.
> Additionally, freeze times can be made easier, as people can commit
> their changes locally and only push them within the timeframe when we
> open the tree.
> Also having one repo per language (given we have the glue code to pull
> what's needed on build machines or for --enable-ui-language builds) can
> help with permissions management, adding new locales, etc - even though
> it makes cross-language mass changes harder.
>
> If those assumptions really hold true for hg (I'm judging them from my
> private useage of git, mainly), than I think it may be a good idea to
> switch some time. (For what I heard, the DVCSes are quite similar, esp.
> git/hg.) The switch doesn't necessarily need to be at the same tiome as
> development switches to mozilla-central though, as repos are already
> decoupled, it's just a question of the glue code.
>
> Robert Kaiser

Yes, your assumptions should hold, as well as the problems you're
pointing out. I.e., cross-locale work will get harder, I hope to have it
stay within a reasonable limit. For my own sanity ;-)

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Damjan Georgievski
In reply to this post by Axel Hecht
> Anyway, I'd like to get your comments.

we already use Mercurial for the mk locale, and although we are only 2
people commit-ing, it's much much easier to use than when we tried to
synchronize through the mozilla CVS.

+1

ps.
cvs sucks big time, so anything is better.
 
--
damjan
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Hubert Gajewski
In reply to this post by Simon Paquet-2
Simon Paquet pisze:
> Justin Wood (Callek) wrote on 16. May 2008:
>
>> Given that *anyone* wanting to build Firefox (or many other
>> applications soon), will need to learn at least to some extent Hg, so
>> "yet another tool" will be applied *anyway* to majority of people
>> (current localizers included).
>
> Localizers normally do not build the applications themselves, at least
> the Calendar localizers that I know don't.

I do it. Mozilla does not build Lightning (trunk) for localized versions so:
http://l10n.mozilla.org/~hubert/pub/calendar/lightning/nightly/latest-trunk-l10n/
http://l10n.mozilla.org/~hubert/pub/calendar/lightning/nightly/latest-mozilla1.8-l10n/

Hubert
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Jesper Kristensen-4
In reply to this post by Axel Hecht
Axel Hecht skrev:

> Jesper Kristensen wrote:
>> Axel Hecht skrev:
>>> Hi all,
>>>
>>> I'd like to open a discussion on migrating our localizations over
>>> from cvs to mercurial for firefox.next.
>>
>> I am a website localizer working in svn, so I arguably cannot speak
>> for product localizers, but I will do that anyway.
>>
>> I think it would be best to have en-US and locales in the same VCS and
>> directory structure. Be that cvs or hg.
>
> There'd be two ways to do this, I guess:
>
> Move en-US off the main rep, or move l10n into that. Moving en-US off is
> something that I don't see happening, really. Moving l10n into would
> require localizers to get contributor access to the main rep, which
> would raise the bar of their technical capabilities significantly. Which
> is the only reason why we moved them off initially.

I don't see how having the same VCS and directory structure for both
en-US and loceles would imply having them in the same repository. Or am
I misunderstanding you?

>
> I agree that it's a somewhat awkward compromise, but that's the nature
> of compromises, I guess.
>
>> I have heard a complaint that it is nearly impossible in CVS to share
>> work on localization when the tree is closed (e.g. for beta release).
>> Would hg be able to solve that?
>
> Yeah, that sucked for beta, but we have a solution for that problem now.
> There is a bonsai query based on cvs modules that only contains the
> frozen directories.

Are you talking about updating other products when Firefox is frozen? I
was talking about updating Firefox when Firefox was frozen.

>
> hg would be different, and I can't really say how. We wouldn't really
> branch in hg, but clone reps. Which isn't really saying a whole lot
> about how things would work in times of tree closure for creating builds
> and such. I'll re-raise the question in .planning.
>
> Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
Reply | Threaded
Open this post in threaded view
|

Re: l10n, mozilla-central, and mercurial (hg)

Axel Hecht
Jesper Kristensen wrote:

> Axel Hecht skrev:
>> Jesper Kristensen wrote:
>>> Axel Hecht skrev:
>>>> Hi all,
>>>>
>>>> I'd like to open a discussion on migrating our localizations over
>>>> from cvs to mercurial for firefox.next.
>>>
>>> I am a website localizer working in svn, so I arguably cannot speak
>>> for product localizers, but I will do that anyway.
>>>
>>> I think it would be best to have en-US and locales in the same VCS
>>> and directory structure. Be that cvs or hg.
>>
>> There'd be two ways to do this, I guess:
>>
>> Move en-US off the main rep, or move l10n into that. Moving en-US off
>> is something that I don't see happening, really. Moving l10n into
>> would require localizers to get contributor access to the main rep,
>> which would raise the bar of their technical capabilities
>> significantly. Which is the only reason why we moved them off initially.
>
> I don't see how having the same VCS and directory structure for both
> en-US and loceles would imply having them in the same repository. Or am
> I misunderstanding you?

Well, same directory structure somehow does. At least in the ones I have
in mind. Any proposals from your side?

>>
>> I agree that it's a somewhat awkward compromise, but that's the nature
>> of compromises, I guess.
>>
>>> I have heard a complaint that it is nearly impossible in CVS to share
>>> work on localization when the tree is closed (e.g. for beta release).
>>> Would hg be able to solve that?
>>
>> Yeah, that sucked for beta, but we have a solution for that problem
>> now. There is a bonsai query based on cvs modules that only contains
>> the frozen directories.
>
> Are you talking about updating other products when Firefox is frozen? I
> was talking about updating Firefox when Firefox was frozen.
>

Oh, the point of freezing Firefox is freezing Firefox, of course. That
does imply no updates. As others have pointed out, working in a dvcs
offers solutions, as you can check-in, and even push to your own shared
repos without actually pushing to the official repo.

Axel
_______________________________________________
dev-l10n mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-l10n
12