The en-US hierarchy

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

The en-US hierarchy

Rimas Kudelis
Hi,

IIRC, somebody here had a nice shell script which would produce a proper
en-US symlink hierarchy pointing to mozilla-central and comm-central. Or
something like that.

If you still have it, would you please share it? Thanks in advance!


Alternatively, a question to the L10n drivers: could we get a
strings-only repo for en-US for mozilla/comm-central, -aurora and -beta,
like we already have for gaia? Updating three mozilla- repositories
after each tree migration is curretly a pain in the aß*, because of the
enormous amount of new commits for each release. I'd gladly avoid this
"fun", if I could. I remember Frenchmozilla once offered such a repo,
but I think it's been discontinued at some point... :(

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

Re: The en-US hierarchy

Axel Hecht
On 11/11/14 9:20 PM, Rimas Kudelis wrote:
> Hi,
>
> IIRC, somebody here had a nice shell script which would produce a proper
> en-US symlink hierarchy pointing to mozilla-central and comm-central. Or
> something like that.
>
> If you still have it, would you please share it? Thanks in advance!

I don't have one, but I'm also wondering about the benefit of it?

> Alternatively, a question to the L10n drivers: could we get a
> strings-only repo for en-US for mozilla/comm-central, -aurora and -beta,
> like we already have for gaia? Updating three mozilla- repositories
> after each tree migration is curretly a pain in the aß*, because of the
> enormous amount of new commits for each release. I'd gladly avoid this
> "fun", if I could. I remember Frenchmozilla once offered such a repo,
> but I think it's been discontinued at some point... :(

The gaia-l10n repos are a mixed bag. They're cool because they're small,
but they're also a pain, 'cause they get broken every now and then.
Given that the size of the repository and contributor base for Firefox
is much larger than for fxos, I expect more bustages there, too.

Here's what I'm working on/thinking about instead.

a) get together with gps to formalize and document a single-repo
multiple-heads setup.
http://gregoryszorc.com/blog/2014/06/30/track-firefox-repositories-with-local-only-mercurial-tags/ 
is a good place to start reading upon his thoughts. He doesn't know that
yet, too :-)

This should significantly reduce the amount of cloning and yadda yikes
whatnot. Hook up convenience hg extensions to make `hg push` and `hg
pull` do the right thing. Also, on migration day, you don't pull three
repos, as you have all the changesets locally. You'd just shift some
bookmarks around in your local clone. Seconds instead of mega bytes.

b) get Aisle up and out there. Aisle will have convenience hooks that
will just work out where a file is in your localization, and where in
en-US. Create directories if needed. Just all those awkward "I need a
shell script 'cause I do this 10 times a day" stuff. It's actually
pretty trivial to open up a "tab" from a compare-locales output.

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

Re: The en-US hierarchy

Ognyan Kulev-3
In reply to this post by Rimas Kudelis
На 11.11.2014 г. в 22:20 ч., Rimas Kudelis написа:
> IIRC, somebody here had a nice shell script which would produce a proper
> en-US symlink hierarchy pointing to mozilla-central and comm-central. Or
> something like that.
>
> If you still have it, would you please share it? Thanks in advance!

Python scripts that automate creating and updating POT files, and
meanwhile create en-US:

https://bitbucket.org/ogi/mozilla-l10n-po/src

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

Re: The en-US hierarchy

Rimas Kudelis
In reply to this post by Rimas Kudelis
2014.11.12 08:22, Ognyan Kulev rašė:

> На 11.11.2014 г. в 22:20 ч., Rimas Kudelis написа:
>> IIRC, somebody here had a nice shell script which would produce a proper
>> en-US symlink hierarchy pointing to mozilla-central and comm-central. Or
>> something like that.
>>
>> If you still have it, would you please share it? Thanks in advance!
>
> Python scripts that automate creating and updating POT files, and
> meanwhile create en-US:
>
> https://bitbucket.org/ogi/mozilla-l10n-po/src

Thanks! Will try these. :)

Rimas


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

Re: The en-US hierarchy

Rimas Kudelis
In reply to this post by Axel Hecht
2014.11.12 03:47, Axel Hecht rašė:

> On 11/11/14 9:20 PM, Rimas Kudelis wrote:
>> Hi,
>>
>> IIRC, somebody here had a nice shell script which would produce a proper
>> en-US symlink hierarchy pointing to mozilla-central and comm-central. Or
>> something like that.
>>
>> If you still have it, would you please share it? Thanks in advance!
>
> I don't have one, but I'm also wondering about the benefit of it?

Just something I got used to – opening the en-US file in one terminal
tab and lt file in the other. Not even sure I'll still need that now
that we have everything except SeaMonkey in Pootle....

>> Alternatively, a question to the L10n drivers: could we get a
>> strings-only repo for en-US for mozilla/comm-central, -aurora and -beta,
>> like we already have for gaia? Updating three mozilla- repositories
>> after each tree migration is curretly a pain in the aß*, because of the
>> enormous amount of new commits for each release. I'd gladly avoid this
>> "fun", if I could. I remember Frenchmozilla once offered such a repo,
>> but I think it's been discontinued at some point... :(
>
> The gaia-l10n repos are a mixed bag. They're cool because they're small,
> but they're also a pain, 'cause they get broken every now and then.
> Given that the size of the repository and contributor base for Firefox
> is much larger than for fxos, I expect more bustages there, too.

Can't this be as simple as a scheduled bunch of recursive copies and a
commit afterwards?


> Here's what I'm working on/thinking about instead.
>
> a) get together with gps to formalize and document a single-repo
> multiple-heads setup.
> http://gregoryszorc.com/blog/2014/06/30/track-firefox-repositories-with-local-only-mercurial-tags/
> is a good place to start reading upon his thoughts. He doesn't know that
> yet, too :-)


I never really understood why Mozilla chose this "we'll have N separate
repos with same changesets" path. It's good to know that somebody is
looking for ways to workaround this huge inconvenience.


> This should significantly reduce the amount of cloning and yadda yikes
> whatnot. Hook up convenience hg extensions to make `hg push` and `hg
> pull` do the right thing. Also, on migration day, you don't pull three
> repos, as you have all the changesets locally. You'd just shift some
> bookmarks around in your local clone. Seconds instead of mega bytes.

(y)

> b) get Aisle up and out there. Aisle will have convenience hooks that
> will just work out where a file is in your localization, and where in
> en-US. Create directories if needed. Just all those awkward "I need a
> shell script 'cause I do this 10 times a day" stuff. It's actually
> pretty trivial to open up a "tab" from a compare-locales output.


(y) again. :)

Rimas



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

Re: The en-US hierarchy

Axel Hecht
On 11/12/14 9:35 PM, Rimas Kudelis wrote:

> 2014.11.12 03:47, Axel Hecht rašė:
>> On 11/11/14 9:20 PM, Rimas Kudelis wrote:
>>> Hi,
>>>
>>> IIRC, somebody here had a nice shell script which would produce a proper
>>> en-US symlink hierarchy pointing to mozilla-central and comm-central. Or
>>> something like that.
>>>
>>> If you still have it, would you please share it? Thanks in advance!
>>
>> I don't have one, but I'm also wondering about the benefit of it?
>
> Just something I got used to – opening the en-US file in one terminal
> tab and lt file in the other. Not even sure I'll still need that now
> that we have everything except SeaMonkey in Pootle....
>
>>> Alternatively, a question to the L10n drivers: could we get a
>>> strings-only repo for en-US for mozilla/comm-central, -aurora and -beta,
>>> like we already have for gaia? Updating three mozilla- repositories
>>> after each tree migration is curretly a pain in the aß*, because of the
>>> enormous amount of new commits for each release. I'd gladly avoid this
>>> "fun", if I could. I remember Frenchmozilla once offered such a repo,
>>> but I think it's been discontinued at some point... :(
>>
>> The gaia-l10n repos are a mixed bag. They're cool because they're small,
>> but they're also a pain, 'cause they get broken every now and then.
>> Given that the size of the repository and contributor base for Firefox
>> is much larger than for fxos, I expect more bustages there, too.
>
> Can't this be as simple as a scheduled bunch of recursive copies and a
> commit afterwards?

The problem here is really making the "copy" stuff fool-proof.

I also think that we'll eventually benefit from having commit messages
for the en-US strings in the translation interface. This is what the
gaia infra does right now. But that makes rolling back to fix errors
really tedious, and basically there's one guy on the planet that knows
how to do those. Bad mojo.

>> Here's what I'm working on/thinking about instead.
>>
>> a) get together with gps to formalize and document a single-repo
>> multiple-heads setup.
>> http://gregoryszorc.com/blog/2014/06/30/track-firefox-repositories-with-local-only-mercurial-tags/
>> is a good place to start reading upon his thoughts. He doesn't know that
>> yet, too :-)
>
>
> I never really understood why Mozilla chose this "we'll have N separate
> repos with same changesets" path. It's good to know that somebody is
> looking for ways to workaround this huge inconvenience.

"It sounded like a good idea at the time". Back in the days when we set
this up, git sucked badly on windows. hg's way of branching was separate
repos at the time. Today, hg bookmarks are a thing instead.

It's just a learning curve on both the DVCS communities, and mozilla.

And the rest is just the amount of energy it takes to turn a ship of the
size of mozilla just a few degrees.

>> This should significantly reduce the amount of cloning and yadda yikes
>> whatnot. Hook up convenience hg extensions to make `hg push` and `hg
>> pull` do the right thing. Also, on migration day, you don't pull three
>> repos, as you have all the changesets locally. You'd just shift some
>> bookmarks around in your local clone. Seconds instead of mega bytes.
>
> (y)
>
>> b) get Aisle up and out there. Aisle will have convenience hooks that
>> will just work out where a file is in your localization, and where in
>> en-US. Create directories if needed. Just all those awkward "I need a
>> shell script 'cause I do this 10 times a day" stuff. It's actually
>> pretty trivial to open up a "tab" from a compare-locales output.
>
>
> (y) again. :)

Thanks

Axel

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