[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (forw) Re: Launching a NMU campaign for pending l10n bugs

> >Of course, as you explain later, for translators they are.s
> ??  Now I'm officially confused.

Well, it's pretty hard to explain.

From a technical point of view, there is absolutely no difference
between the work you do on, say, iso-codes, console-data, xorg,

All of them are debconf templates translations, or programs

The only thing that is special for them is that they are *prioritized*
in your taks before other translations because they are considered
related to the translation of the Debian Installer. Ie, as Frans
explained, translating them is working on a full translation of the
installation process because some of their material is used during the
installation process.

> >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?
> *********

No. This will not help in any matter.

> 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?


> 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. :(

This is what we're trying to solve, yes.

Attachment: signature.asc
Description: Digital signature

Reply to: