l10n, mozilla-central, and mercurial (hg)
Axel Hecht
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
Hasse
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
Axel Hecht
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
Simon Paquet
>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
Justin Wood (Callek)
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)
Simon Paquet
> 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.
Axel Hecht
> 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
Jesper Kristensen
> 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?
Stefan Plewako
> 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
Francesco Lodolo
> They do pull en-US sources, though, right?
en-US and export them to CVS structure (and I'm wondering if it will be
possible to continue using it).
Francesco.
Axel Hecht
Can you clarify? I could guess what you saying, but I'd rather not.
"Import strings from en-US" means exactly what?
Axel
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.
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
Francesco Lodolo
> Can you clarify? I could guess what you saying, but I'd rather not.
> "Import strings from en-US" means exactly what?
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
Axel Hecht
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
Robert Kaiser
> 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
Axel Hecht
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
Damjan Georgievski
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
Hubert Gajewski
> 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
Jesper Kristensen
> 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.
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?
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
Filip Miletic
> 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.
I beg to differ.
Not everyone has constant access to broadband, and working with CVS
offline is a pain. I like to take a laptop on a train and translate
there, CVS makes this more difficult than it should be.
I for one don't care about possible extra used disk space, and welcome
our hg overlords.
Further, if the localizers want to "outsource" the development (i.e.
prepare own work, then commit to Mozilla), it's much easier to achieve
with a distributed version control.
When you are doing some work, it's always a good idea to know your
tools. So it's also a good idea to learn hg, as it is a tool and an
useful one.
IMHO, hg is +1.
f
Rimas Kudelis
If you don't use CVS checkout for en-US, then I suppose you will not be
forced to use Hg on it either.
Many of us already use two tools – CVS and SVN. I think learning one
more tool won't be much of a problem (at least for tech people like
myself). Especially considering that many will learn it to check-out anyway.
Anyway, no matter what the final decision would be, my vote is to unify
the VCS tools we use in mozilla. Be it CVS, SVN or Hg.
RQ
Rimas Kudelis
> 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
I think I heard it does now...
RQ
Ricardo Palomares Martinez
> 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.
FWIW, MozillaTranslator doesn't hardcode anything as of now. It
somehow did it in the past (but no longer does it), assuming that the
directory depth wouldn't ever go beyond 2 levels.
This topic makes me bring up two questions:
- any news about L20n for Mozilla 2? Now, *that* would mean a lot of
changes (spelled like in "challenges", but also like in "benefits") in
the game rules.
- any plan to change the L10n directory structure when migrating to
Mercurial? If the path to ab-CD files would be completely equivalent
to the en-US files, like:
/mozilla/browser/locales/en-US/chrome/browser.dtd
vs.
/mozilla/browser/locales/es-ES/chrome/browser.dtd
instead of
/l10n/es-ES/browser/chrome/browser.dtd
it would ease some features of L10n tools.
JM2C
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Rimas Kudelis
> 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 think he means this difference:
mozilla/browser/locales/en-US
mozilla/browser/locales/en-US/installer
mozilla/browser/locales/en-US/microsummary-generators
mozilla/browser/locales/en-US/crashreporter
mozilla/browser/locales/en-US/searchplugins
mozilla/browser/locales/en-US/profile
mozilla/browser/locales/en-US/profile/unix
mozilla/browser/locales/en-US/profile/win
mozilla/browser/locales/en-US/profile/mac
mozilla/browser/locales/en-US/profile/chrome
mozilla/browser/locales/en-US/updater
mozilla/browser/locales/en-US/chrome
mozilla/browser/locales/en-US/chrome/overrides
mozilla/browser/locales/en-US/chrome/browser
mozilla/browser/locales/en-US/chrome/browser/migration
mozilla/browser/locales/en-US/chrome/browser/places
mozilla/browser/locales/en-US/chrome/browser/preferences
mozilla/browser/locales/en-US/chrome/browser/sidebar
mozilla/browser/locales/en-US/chrome/browser/feeds
mozilla/browser/locales/en-US/chrome/browser/safebrowsing
mozilla/browser/locales/en-US/chrome/browser/history
mozilla/browser/locales/en-US/chrome/help
mozilla/browser/locales/en-US/chrome/browser-region
mozilla/browser/locales/en-US/chrome/branding
mozilla/browser/locales/en-US/os2
vs.
lt/browser
lt/browser/installer
lt/browser/microsummary-generators
lt/browser/crashreporter
lt/browser/searchplugins
lt/browser/profile
lt/browser/profile/unix
lt/browser/profile/win
lt/browser/profile/mac
lt/browser/profile/chrome
lt/browser/updater
lt/browser/chrome
lt/browser/chrome/overrides
lt/browser/chrome/browser
lt/browser/chrome/browser/migration
lt/browser/chrome/browser/places
lt/browser/chrome/browser/preferences
lt/browser/chrome/browser/sidebar
lt/browser/chrome/browser/feeds
lt/browser/chrome/browser/safebrowsing
lt/browser/chrome/browser/history
lt/browser/chrome/help
lt/browser/chrome/browser-region
lt/browser/chrome/branding
lt/browser/os2
I guess the suggestion would be to move mozilla/XXX/locales/en-US/YYY
over to mozilla/en-US/XXX/YYY or something. This would at least make
directory comparisons easier. On the other hand, it would split
application sources even more...
Anyway, isn't l20n a target for Firefox.next? If so, then depending on
how much the things change in the future, we may find ourselves in a
completely different situation, where this particular problem would be
irrelevant. For example, I personally feel that gettext-style strings
ID's (where English string IS itself an ID) are much nicer than our
current someUniqueIdentifier2.label ID's.
RQ
Axel Hecht
> Axel Hecht escribió:
>> 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.
>
>
> FWIW, MozillaTranslator doesn't hardcode anything as of now. It
> somehow did it in the past (but no longer does it), assuming that the
> directory depth wouldn't ever go beyond 2 levels.
Good to hear.
> This topic makes me bring up two questions:
>
> - any news about L20n for Mozilla 2? Now, *that* would mean a lot of
> changes (spelled like in "challenges", but also like in "benefits") in
> the game rules.
>
> - any plan to change the L10n directory structure when migrating to
> Mercurial? If the path to ab-CD files would be completely equivalent
> to the en-US files, like:
>
> /mozilla/browser/locales/en-US/chrome/browser.dtd
>
> vs.
>
> /mozilla/browser/locales/es-ES/chrome/browser.dtd
>
> instead of
>
> /l10n/es-ES/browser/chrome/browser.dtd
>
> it would ease some features of L10n tools.
Mind detailing? Like, as far as I'm concerned, the directory structure
is still semi-random, with more or less arbitrary parts of the path
being substituted. This might work as long as you assume that you're
localizing en-US, but some localizations don't, IIRC. I haven't had that
much problems with the directory structure in my codings so far, so I'm
wondering where you see the advantage.
I do see a counter argument in going for, say,
l10n/browser/locales/es-ES/chrome, one would be that it makes it harder
to check out one localization. Not sure if it would in the hg world,
where we like would end up with a
l10n-central-es-ES/path/to/dir/file.ext
anyway.
But just starting with /mozilla/ sounds like something that's not going
to work. Unless I get a good idea from someone on how so.
Axel
Axel Hecht
As I said in another leaf in this thread, I assume that the "mozilla"
top-level directory will remain holy for l10n.
> Anyway, isn't l20n a target for Firefox.next? If so, then depending on
> how much the things change in the future, we may find ourselves in a
> completely different situation, where this particular problem would be
> irrelevant. For example, I personally feel that gettext-style strings
> ID's (where English string IS itself an ID) are much nicer than our
> current someUniqueIdentifier2.label ID's.
Firefox.next is not a target for l20n, AFAICT. Note, pending
enlightening posts on .planning, that Firefox.next is not Mozilla2.
I strongly believe that looking up strings by en-US value is flawed, and
doesn't solve any problems. It's just foobar.
We'll learn more about that this summer I hope.
But the localization architecture to use doesn't impact the directory
structure of the source at all, really.
Axel
Rimas Kudelis
I'm not suggesting to move all localizations into mozilla tree, I'm
merely suggesting to have all en-US strings in a separate directory in
"mozilla".
>> Anyway, isn't l20n a target for Firefox.next? If so, then depending on
>> how much the things change in the future, we may find ourselves in a
>> completely different situation, where this particular problem would be
>> irrelevant. For example, I personally feel that gettext-style strings
>> ID's (where English string IS itself an ID) are much nicer than our
>> current someUniqueIdentifier2.label ID's.
>
> Firefox.next is not a target for l20n, AFAICT. Note, pending
> enlightening posts on .planning, that Firefox.next is not Mozilla2.
OIC
> I strongly believe that looking up strings by en-US value is flawed, and
> doesn't solve any problems. It's just foobar.
Well, it seems to work well for Gettext.
RQ
Abdulkadir Topal
> Hi all,
>
> I'd like to open a discussion on migrating our localizations over from
> cvs to mercurial for firefox.next.
Please consider that there are a lot of even free programs which handle
CVS via a simple UI, be it TortoiseCVS or something else and these tools
are available for all platforms, whereas there are no such tools for
Mercurial as far as I can tell.
Now, It's not a big deal for me, but I guess quite a lot of localizers
rely on these tools to get the work done, confronting them with not only
CVS but a distributed VCS may be quite frightening. Consider that it's
even difficult for developers to grasp DCVSs and localizers aren't
developers. In an ideal world Mozilla would offer XP tools, which don't
have to be as sophisticated as TortoiseCVS, but at least get the work
done, without resorting to the command line.
Personally I don't see much harm in moving to Mercurial, but frankly I
don't see much benefit either (that is for L10n).
--Abdulkadir
Axel Hecht
I don't get it, sorry.
>>> Anyway, isn't l20n a target for Firefox.next? If so, then depending
>>> on how much the things change in the future, we may find ourselves in
>>> a completely different situation, where this particular problem would
>>> be irrelevant. For example, I personally feel that gettext-style
>>> strings ID's (where English string IS itself an ID) are much nicer
>>> than our current someUniqueIdentifier2.label ID's.
>>
>> Firefox.next is not a target for l20n, AFAICT. Note, pending
>> enlightening posts on .planning, that Firefox.next is not Mozilla2.
>
> OIC
>
>> I strongly believe that looking up strings by en-US value is flawed,
>> and doesn't solve any problems. It's just foobar.
>
> Well, it seems to work well for Gettext.
Sorry, but it just plain doesn't. I've heard numerous reports of
translation errors due to ambiguous English strings showing up in
different contexts in plain gettext systems.
Axel
Axel Hecht
> Axel Hecht schrieb:
>> Hi all,
>>
>> I'd like to open a discussion on migrating our localizations over from
>> cvs to mercurial for firefox.next.
>
> Please consider that there are a lot of even free programs which handle
> CVS via a simple UI, be it TortoiseCVS or something else and these tools
> are available for all platforms, whereas there are no such tools for
> Mercurial as far as I can tell.
>
> Now, It's not a big deal for me, but I guess quite a lot of localizers
> rely on these tools to get the work done, confronting them with not only
> CVS but a distributed VCS may be quite frightening. Consider that it's
> even difficult for developers to grasp DCVSs and localizers aren't
> developers. In an ideal world Mozilla would offer XP tools, which don't
> have to be as sophisticated as TortoiseCVS, but at least get the work
> done, without resorting to the command line.
http://tortoisehg.sourceforge.net/ :-) One of the windows hg installers
actually already comes with that.
> Personally I don't see much harm in moving to Mercurial, but frankly I
> don't see much benefit either (that is for L10n).
>
> --Abdulkadir
Axel
Abdulkadir Topal
> Abdulkadir Topal wrote:
>> Axel Hecht schrieb:
>>> Hi all,
>>>
>>> I'd like to open a discussion on migrating our localizations over
>>> from cvs to mercurial for firefox.next.
>>
>> Please consider that there are a lot of even free programs which
>> handle CVS via a simple UI, be it TortoiseCVS or something else and
>
> actually already comes with that.
Oops, sorry, I should have looked it up, there were non, when I looked a
few month ago.
--Abdulkadir
Rimas Kudelis
Trying again.
You currently have en-US in the main repo ("mozilla/" directory), and
these files are scattered all around the tree. An example of such filename:
mozilla/browser/locales/en-US/chrome/browser/migration/SomeFile.dtd
Meanwhile all translations are in a separate repo (l10n/ directory), AND
use a slightly different directory structure. E.g., the above en-US file
corresponds to the following file in lt:
l10n/lt/browser/chrome/browser/migration/SomeFile.dtd
Now, like you said, moving stuff from l10n/ into mozilla/ is very
unlikely, but we're not suggesting that. Our (my) suggestion is to move
stuff from e.g.:
mozilla/browser/locales/en-US/chrome/browser/migration/SomeFile.dtd
to, for example,
mozilla/en-US/browser/chrome/browser/migration/SomeFile.dtd
Note the "mozilla/" part remains sacred, and I'm not suggesting to move
l10n/lt/ into it. The suggestion is simply to have the directory tree
equivalent between en-US and other languages, to make comparison simpler.
>>>> Anyway, isn't l20n a target for Firefox.next? If so, then depending
>>>> on how much the things change in the future, we may find ourselves
>>>> in a completely different situation, where this particular problem
>>>> would be irrelevant. For example, I personally feel that
>>>> gettext-style strings ID's (where English string IS itself an ID)
>>>> are much nicer than our current someUniqueIdentifier2.label ID's.
>>>
>>> Firefox.next is not a target for l20n, AFAICT. Note, pending
>>> enlightening posts on .planning, that Firefox.next is not Mozilla2.
>>
>> OIC
>>
>>> I strongly believe that looking up strings by en-US value is flawed,
>>> and doesn't solve any problems. It's just foobar.
>>
>> Well, it seems to work well for Gettext.
>
> Sorry, but it just plain doesn't. I've heard numerous reports of
> translation errors due to ambiguous English strings showing up in
> different contexts in plain gettext systems.
Of course there can be ambiguity, but it's simple to deal with. You
could always prepend something to the string to make it unique, and cut
that prepended part away when displaying the string. It still makes the
translation easier because you don't have to look the string up in one
file, and translate it in the other.
OTOH, I got quite accustomed to the current translation scheme. And as a
person who actually uses an ordinary text editor to translate, I can't
even blame this current scheme for being uncomfortable.
RQ
Ricardo Palomares Martinez
>> - any plan to change the L10n directory structure when migrating to
>> Mercurial? If the path to ab-CD files would be completely equivalent
>> to the en-US files, like:
>>
>> /mozilla/browser/locales/en-US/chrome/browser.dtd
>>
>> vs.
>>
>> /mozilla/browser/locales/es-ES/chrome/browser.dtd
>>
>> instead of
>>
>> /l10n/es-ES/browser/chrome/browser.dtd
>>
>> it would ease some features of L10n tools.
>
> Mind detailing? Like, as far as I'm concerned, the directory structure
> is still semi-random, with more or less arbitrary parts of the path
> being substituted. This might work as long as you assume that you're
> localizing en-US, but some localizations don't, IIRC. I haven't had that
> much problems with the directory structure in my codings so far, so I'm
> wondering where you see the advantage.
Maybe you use calls to Python scripts, downloaded from the repository,
that keep track of the relationship between en-US and ab-CD
directories? For L10n tools, that relationship is going to be manually
managed by users, or hard coded in the tool, or else the tool would
need to parse the script (if such one exists). If we could avoid this,
it would be better.
> I do see a counter argument in going for, say,
> l10n/browser/locales/es-ES/chrome, one would be that it makes it harder
> to check out one localization.
That's true. I like Rimas' suggestion, to adapt en-US instead,
although I guess that's not possible either because of module owner
permissions and so. Would symbolic links fit here?
Ricardo
Axel Hecht
I'm not sure that it's a good compromise to move the localized files
into one single top-level dir. I'm pretty confident that it's out of the
scope for firefox.next.
Currently, the list of directories is encoded in client.mk. That's
pretty cumbersome, and so far, I haven't found a better way to get the
values out than to do a
make -f client.mk echo-variable-LOCALES_browser
and friends. At least that works in an automated way.
Maybe we should just put that data into a separate text file for
firefox.next, now that client.mk is dead anyway. An ini file or json or
something.
Axel