different EN branches for Fx and Tb central

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

different EN branches for Fx and Tb central

Vito Smolej-3
fx central(en_branch):  mozilla-central
comm-central( en_branch) : comm-central

Huh?!

If the common locales/en-US are identical, it would be good to let us
know. If, however, (dom, editor, toolkit...)  locales/en-US are
different, then it looks to me like a race - the first one to localize
will have the pleasure of p*ssing off the rest.

Same situation in beta:

fx beta     releases/mozilla-beta
tb beta     releases/comm-beta

but there both SL positions are green in SL, so :"... break-even and
let's play the next round".

Regards

smo



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

Re: different EN branches for Fx and Tb central

flod
Il 13/07/11 20.51, smo ha scritto:
> fx central(en_branch):  mozilla-central
> comm-central( en_branch) : comm-central
>
> Huh?!
>
> If the common locales/en-US are identical, it would be good to let us
> know. If, however, (dom, editor, toolkit...)  locales/en-US are
> different, then it looks to me like a race - the first one to localize
> will have the pleasure of p*ssing off the rest.
Not sure what's the problem here: comm-central and mozilla-central don't
overlap (e.g. toolkit, dom, security are not available in comm-*), en-US
Thunderbird nightly builds will use strings from mozilla-central for
toolkit/dom/etc.

If different people work on different products, you'll have to
coordinate the localization of common parts. For example, in Italian I
take care of all common modules (toolkit, dom, security, netwerk)
besides working on browser and mobile.

Francesco

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

Re: different EN branches for Fx and Tb central

Justin Wood (Callek)-2
In reply to this post by Vito Smolej-3
On 7/13/2011 2:51 PM, smo wrote:

> fx central(en_branch):  mozilla-central
> comm-central( en_branch) : comm-central
>
> Huh?!
>
> If the common locales/en-US are identical, it would be good to let us
> know. If, however, (dom, editor, toolkit...)  locales/en-US are
> different, then it looks to me like a race - the first one to localize
> will have the pleasure of p*ssing off the rest.
>
> Same situation in beta:
>
> fx beta     releases/mozilla-beta
> tb beta     releases/comm-beta
>
> but there both SL positions are green in SL, so :"... break-even and
> let's play the next round".
>

comm-* (central for example) uses client.py to checkout mozilla-central
as well.

This allows us to have a structure in comm that include mozilla, and our
apps use mozilla strings directly from mozilla-central.

Your l10n repos have everything flat, which means the following are all
side-by-side

*suite
*mail
*toolkit
*content
...

When you have people working on different products, you will note that
no-one really needs to do tons of extra work, since the majority of
strings are in *core* (fx based strings), and minimal changes are
necessary for tb or seamonkey. tb and seamonkey use many of the same
strings as fx (basically anything not in browser/ is shared by tb and
seamonkey in some way).

--
~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: different EN branches for Fx and Tb central

Vito Smolej-3
On Jul 14, 5:55 am, "Justin Wood (Callek)" <[hidden email]> wrote:

> On 7/13/2011 2:51 PM, smo wrote:
>
>
>
>
>
>
>
>
>
> > fx central(en_branch):  mozilla-central
> > comm-central(      en_branch) : comm-central
>
> > Huh?!
>
> > If the common locales/en-US are identical, it would be good to let us
> > know. If, however, (dom, editor, toolkit...)  locales/en-US are
> > different, then it looks to me like a race - the first one to localize
> > will have the pleasure of p*ssing off the rest.
>
> > Same situation in beta:
>
> > fx beta         releases/mozilla-beta
> > tb beta         releases/comm-beta
>
> > but there both SL positions are green in SL, so :"... break-even and
> > let's play the next round".
>
> comm-* (central for example) uses client.py to checkout mozilla-central
> as well.
>
> This allows us to have a structure in comm that include mozilla, and our
> apps use mozilla strings directly from mozilla-central.
>
> Your l10n repos have everything flat, which means the following are all
> side-by-side
>
> *suite
> *mail
> *toolkit
> *content
> ...
>
> When you have people working on different products, you will note that
> no-one really needs to do tons of extra work, since the majority of
> strings are in *core* (fx based strings), and minimal changes are
> necessary for tb or seamonkey. tb and seamonkey use many of the same
> strings as fx (basically anything not in browser/ is shared by tb and
> seamonkey in some way).
>
> --
> ~Justin Wood (Callek)

I feel normal again (g). Thanks Justin! One thing we localizers
definitely do not need, is stepping on each other's toes. Theres
not that many available anyhow, as you probably know (g). And,
of course, an unintentional fork would cause a foobar situation.
Hence my paranoia.

As Flod indicated, common parts must in any case have a driver,
(a designated hitter;) and per default it's Matjaz in SL case.
Means, if I jump  in now and then into dom or toolkit etc, doing TB,
 my contribution should still pass his doors.  Which  I confess,
was not always  the case - some (long) time ago.

It just took such a long time and learning curve to get out of
the TB 2.0 hole...

Regards

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