Re: Source L10n for extensions (ChatZilla, venkman and others)

Axel Hecht wrote:
> Robert Kaiser wrote:
>> Robert Kaiser wrote:
>>> So, to me, it seems that the way to go for those extensions is 
>>> something Axel called "dependent langpacks" - which is more or less 
>>> what ChatZilla already uses, but with extension dependency added into 
>>> it (which is ignored on older applications, so ChatZilla langpacks 
>>> can easily add them and still be compatible with older apps).
>>> What this means is that the original extension packages will probably 
>>> all include the en-US locale as previously, and additionally we'll 
>>> have every existing additional language as a separate extension (both 
>>> in SeaMonkey and as XPIs).
>>
>> As it looks to me that there is basic agreement on this as the 
>> technical solution, I filed 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=397246 to work on this 
>> for ChatZilla.
>> I already have some work in progress lying around on my disk for the 
>> SeaMonkey repackaging case, but I consider this quite experimental for 
>> the moment (and of course this depends on ChatZilla being packaged as 
>> an extension within SeaMonkey, which is a different bug).
>>
>> This does not mean that this is set in stone - I can't decide that - 
>> but it's the way I'd like to go for SeaMonkey. I consider what I'm 
>> doing with this now some kind of experiment on how this can work, and 
>> there are still some things I need to figure out.
>> I think we can arrive at a good solution with this though.
> 
> Did anyone actually test that this scheme works? Like, other than in 
> theory? In all releases/branches/apps that are wanted? This is really 
> only a build problem at the very end.
As outlined in my original reply, the idea of language packs for 
extensions has already been used with ChatZilla for quite some time now. 
It has worked fine, I don't see any reason why it should stop working.

> 
> I haven't seen a real commitment from the chatzilla devs on this scheme, 
> either, so I'm unclear on who's owning chatzilla l10n.
If you mean the language pack extension scheme, see above. If you mean 
the way we interact with localizers, that's a different matter.

Up to today, all we did was ship ChatZilla in en-US. If people told us 
they had locale packages, we linked them from the homepage. That's about 
it. I personally don't think we want a formal "chatzilla l10n" owner or 
process at all (but I haven't discussed this with the other devs). What 
the localization teams do is their business as far as ChatZilla is 
concerned, and we will be happy to link to them and/or ask AMO to link 
them from the ChatZilla addon page. We've never had a formal release 
process or dates, and I don't see that changing either, which means a 
locale freeze or something to that effect would only delay the release 
for en-US users, which I don't think is worth it. Toolkit's extension 
manager should be smart enough to warn users when you update an 
extension that it'll break dependent extensions, and if it doesn't do 
that our own code will yell at the user about what happened, and they 
should be able to correct it.

What the SeaMonkey L10N people do is up to them. We stop touching 
ChatZilla on SeaMonkey immediately after the first release, unless there 
are security issues that need to be addressed. We would probably deal 
with l10n freezes on seamonkey's side easily as we don't really check in 
stuff every day or whatever...


~ Gijs