On 17/09/2006, at 1:41 AM, Christian Perrier wrote:
Quoting Frans Pop (firstname.lastname@example.org):On Saturday 16 September 2006 13:52, Clytie Siddall wrote:How about D-I files? Some I can commit, but others I still need to submit by email.If you cannot commit them, they are not D-I.Of course, as you explain later, for translators they are.s
?? Now I'm officially confused.
Remember the "levels". So, from the translation team point of view, files for iso-codes, console-data, xorg, samba, dpkg, etc. are "d-i files". Of course, technically speaking they aren't as you clearly point.
<Clytie starts banging her head on the keyboard> Ouch. *********Just to clarify this pea soup a bit, do I use "D-I" in the subject line of the "d-i" files which need to be submitted by email, or not?
*********I think I understand what you're saying, which is that all the files listed on the D-I pages are "d-i" from the translation POV, but not from the BTS and general Debian structure POV. Is that right?
To answer Clytie's quesiton, getting commit access to all D-I translators for all packages that are part of D-I levels would be a huge hassle and I'm not completely sure that all maintainers would be keen with "random people" getting commit access to "their" repository.
I hope I didn't give the impression that I'm complaining about not having commit access to all the translation-d-i files. Source control is such a large part of my workflow now that it's certainly easier to be able to commit updated translations, but I'm also willing to email them. I realize that widespread commit access can lead to some complex reversions.
So I'm always pleased to be allowed write access for my files, but I certainly don't expect it. :)
So, we slowly established the concept of "l10n assistants" (often myself, sometimes other people) who do the job (and do it well for all packages and also help maintainers to cope with the l10n flux....or sometimes request them for "translation uploads". I see no urgent need to change this now. It works.
I agree. :)The translation-d-i files are not a concern from the BTS-zombie point of view. The debconf files are.
So far, I'm only maintaining translations for program files belonging to developers who have requested them on this list, which integrates the translator into their release cycle, showing a level of organization which in my experience does not leave updated translations to languish in the BTS.
My problems so far are squarely with debconf files. As I said, some of my debconf translations have been submitted and unprocessed for over a year. Since they are nearly all initial translations, that means my community still doesn't have effective access to the Debconf process for that program, despite my effort. That's pretty frustrating for a translator. :(
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do)
Description: This is a digitally signed message part