[I only speak for myself, and not for the french translation team neither
for the ddtp, in which I'm not involved at all. Please flame *me* for what I
say]
On Wed, May 14, 2003 at 08:27:02AM -0400, Theodore Ts'o wrote:
> On Wed, May 14, 2003 at 12:07:29PM +0200, Martin Quinson wrote:
> >
> > Your engagement for the quality of your package is really great. Only, I
> > think that you are not responsible of the translation. I know that there is
> > a lack in debian framework concerning this point, but it really should be so
> > ('cause maintainer cannot be responsible for translations they do not
> > understand. How do you handle tranlations in russian, japaneese and
> > bokmal?).
>
> This is a fundamental question for which there definitely isn't
> consensus, and it is a fundamental polity (governance) issue.
>
> One is that the linguistic teams have full and ultimate responsibility
> over the translations, and there is no recourse or appeal if the
> maintainer doesn't like what they have done.
>
> Another position is that the maintainer is ultimately responsible; he
> or she may delegate responsibility to helpers, just as the Debian
> Leader may delegate certain responsibilities to subordinates.
> However, it is clear that the maintainer or the Debian Leader is
> ultimately responsible, even if the wise maintainer and/or Debian
> Leader may not choose to exercise his or her perogatives very often.
>
> This point is a subtle one. I will point out that in a corporate
> setting, it's quite normal for the employer's manager and or his
> manager's manager will not fully understand all of the work that that
> the employee does. Yet they are still responsible for the work of the
> employee, and if they don't like it, they can tell the employee to do
> things a different way, or in the extreme case, they can fire him.
>
> Obviously, if the manager doesn't completely understand what the
> employee is doing, there will be a certain negotiation, and a certain
> back and forth over goals and directions and what is and isn't
> technically possible, etc. Hopefully, said negotiations will be done
> in a mutally respectful and civil manner. But that doesn't change the
> fact that ultimately the manager gets to have the final say.
>
> Which model people subscribe to makes a lot of difference in how they
> communicate. For example, if your manager doesn't like the work that you
> do, even if you think his grounds for objecting may not be the best
> ones, would you tell him, "tough luck"? Probably not....
>
> - Ted
>
> P.S. To the extent that the DDTP gives the package maintainer veto
> rights, it seems pretty clear that at least initially the DDTP
> believed that the package maintainer was ultimately responsible.
> Given comments and the tenor of the tone made by some of the people on
> some of the language teams, it's not clear they believe that as
> strongly today.
Please keep in mind that I have nothing to do with the DDTP. My advice is
personal.
I completely agree with you on several points, like the fact that there is
no special reason in the constitution or in policy or in BCP or in any
official Debian writting to say that the maintainer is not responsible for
the content of the translations.
I only meant that it's rather illogical to ask to maintainer to review texts
in languages he/she don't understand. I know that this issue is related to
what can be found for porting to architectures the maintainer does not know,
but still, there is some quite fundamental differences here.
Thanks to the wonderfull dbuild architecture, it is very easy to know if
there *is* a problem on a given architecture, and what the right solution
is (apply patches as long as dbuild repports an error).
This is not true for translations, since no mecanical validation is enough.
Even if a text is ispell-clean, there might be a ton of gramatical error,
typographical ones and even badly constructed sentences which do not "sound
well".
Moreover, languages are sometimes difficult even for native speaker. French
is a rather good example of this complexity, and explains why we cam up with
so complicated reviewing processes within our team: webpages are posted at
least three time to the ML, in [ITT] mails for 'intend to translate', [DDR]
for 'ask for review', and [RELU] for 'reviewed, ready to be commited'
emails ; the DDTP integrate a reviewing process where all description have to
be accepted by 3 other translators before being declared as usable by the
end user.
So, if we need so much work to find a good translation when all involved
people are native french speaker, how can you explain that maintainers can
'detect errors in our work' (like the use of the non breaking space ASCII
code to follow our typographical rules), and corrupt our work so easily?
Please note that this discussion, like most of the previous ones on this
topic, is moving from a very simple problem (maintainer shouldn't try to
"fix" translation when they are not native speaker VS translator shouldn't
fix errors in original text without informing the author of this original
text) to a much much more complicated one, being the status of translators
inside debian.
I would be more than pleased to discuss this much more generic problem with
anyone wanting to participate, but on debian-i18n, not in a weird cross-post
between debian-devel and debian-l10n-french (which is supposed to be a
french speaking mailing list).
In order to help the current discution to find an usefull conclusion, I
would like to propose you the following blahblah for inclusion in the debian
reference "Managing packages" chapter, for example after the one on porting
and geting ported. This is very far from being perfect, and I would be more
than happy to discuss it before the actual inclusion. But, please, do
respect the reply-to to debian-i18n, so that we discuss it on the right ML.
Friendly, Mt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Internationalizing, translating and being internationalized and translated
Debian supports an ever-increasing number of natural language. Even if you
are native english speaker and do not speak any other language, it is part
of your duty as a maintainer to be aware of issues of internationalization
(abbreviated i18n because there is 18 letters between the 'i' and the 'n' in
internationalization). Therefore, even if you are ok with english only
programs, you should read most of this chapter.
According to "Introduction to i18n" from Tomohiro KUBOTA,
(http://www.debian.org/doc/manuals/intro-i18n/), "I18N
(internationalization) means modification of a software or related
technologies so that a software can potentially handle multiple languages,
customs, and so on in the world." while "L10N (localization) means
implementation of a specific language for an already internationalized
software."
l10n and i18n are tied, but the difficulties related to each of them are
very different. It's not really difficult to allow the program to change the
language in which texts are displayed based on user settings, but it is very
time consuming to actually translate the messages. On the other hand,
setting the character encoding is trivial, but adapting the code to use
several character encodings is a really hard problem.
Letting alone the i18n problems, where no general receipt exist, there is
actually no central infrastructure for l10n within Debian which could be
compared to the dbuild mecanism for porting. So, most of the work have to be
done manually
How are handled translations within Debian?
===========================================
Handling translation of the texts contained in a package is still a manual
task, and the process depends on the kind of text you want to see
translated.
For program messages, the gettext infrastructure is used most of the time.
Most of the time, the translation is handled upstream within projects like
the Free Translation Project (http://www.iro.umontreal.ca/contrib/po/HTML/),
the Gnome translation Project (http://developer.gnome.org/projects/gtp/) or
the KDE one (http://i18n.kde.org/). The only centralized resource within
Debian is the Central Debian translation statistics
(http://www.debian.org/intl/l10n/), where you can find some statistics about
the translation files found in the actual package, but no real infrastucture
to ease the translation process.
An effort to translate the package descriptions started long ago even very
few support is offered by the tools to actually use them (ie, only APT can
use them, when configured correctly). There is nothing to do for the
maintainers, and the translators should use the DDTP
(http://ddtp.debian.org/).
For debconf templates, maintainer should use the po-debconf package to ease the
work of your translators, which should use the DDTP to do their work. Some
statistics can be found both on the DDTP site (about what is actually
translated), and on the Central Debian translation statistics site
(http://www.debian.org/intl/l10n/ -- about what is integrated in the
packages).
For webpages, each l10n team have access to the relevant CVS, and the
statistics are available from the Central Debian translation statistics site.
For general documentation about debian, the process is more or less the same
than for the webpages (the translators have an access to the CVS), but there
is no statistics pages.
For package specific documentation (man pages, info document, other
formats), almost everything have yet to be done. Most notably, the KDE
project handles translation of its documentation in the same way than its
program messages. Debian specific man pages begin to be handled within a
specific CVS repository (http://cvs.debian.org/manpages/?cvsroot=debian-doc).
I18N & L10N FAQ for maintainers
===============================
This is a list of problems that maintainers may face concerning i18n and
l10n. While reading this, keep in mind that there is no real consensus on
those points within Debian, and that they are only advices. If you have a
better idea for a given problem, or if you disagree on some points, feel
free to provide your feedback, so that this document can be enhanced.
How to get a given text translated?
-----------------------------------
To translate package description or debconf templates, you have nothing to
do, the DDTP infrastructure will dispatch the material to translate to
volunteers with no need for interaction from your part.
For all other material (gettext files, man pages or other documentation),
the best solution is to put your text somewhere on Internet, and ask on
debian-i18n for a translation in the different languages. Some translation
team members are subscribed to this list, and they will take care of the
translation and of the reviewing process. Once done, you will get your
translated document from them in your mailbox.
How to get a given translation reviewed?
----------------------------------------
>From time to time, individuals translate some texts included in your package
and will ask you for inclusion in the package. This can become problematic
if you are not fluent in the given language. It is a good idea to send the
document to the corresponding l10n mailing list, asking for a review. Once
it hase be done, you should feel more confident in the quality of the
traduction, and include it fearlessly into your package.
How to get a given translation updated?
---------------------------------------
If you have some translations of a given text laying around, each time you
update the original, you should kindly ask to the previous translator to
update his/her work to make the translation uptodate with regard to the
current original text. Keep in mind that this task takes time, at least one
week to get the update reviewed and all.
If the translator is unresponsive, you may ask for help to the corresponding
l10n mailling list. If everything fails, don't forget to put a warning in
the translated document, stating that the translation is somehow outdated,
and that the reader should refer to the original document if possible.
Avoid removing completely a translation because it is outdated. An old
documentation is often better than no documentation at all for non-english
speaker.
How to handle a bug repport concerning a translation?
-----------------------------------------------------
The best solution may be to mark the bug as "forwarded to upstream", and
forward it to both the previous translator and his/her team (using the
corresponding debian-l10n-XXX mailing list).
I18N & L10N FAQ for translators?
================================
While reading this, please keep in mind that there is no general procedure
within Debian concerning those points, and that in anycase, you should
collaborate with your team and
How to help the translation effort?
-----------------------------------
Choose what you want to translate, make sure that nobody is already working
on it (using your debian-l10n-XXX mailing list), translate it, get it
reviewed by other native speaker on your l10n mailing list, and provide it
to the maintainer of the package (see next point).
How to provide a translation for inclusion in a package?
--------------------------------------------------------
Make sure that your translation is correct (asking for review on your l10n
mailing list) before providing it for inclusion. It will save time for
everyone, and avoid the chaos resulting in having several version of the
same document in bug repports.
The best solution is to fill a regular bug containing the translation
against the package. Make sure to use the 'PATCH' tag, and to not use a
gravity higher than 'wishlist', since the lack of translation never
prevented a program from running.
BEST CURRENT PRACTICE concerning l10n
=====================================
1. As maintainer, never edit the translations in any way (even to reformat
the layout) without asking to the corresponding l10n mailing list. You
risk for example to break the encoding of the file by doing so. Moreover,
what you consider as an error can be right (or even needed) in the given
language.
2. As translator, if you find an error in the original text, make sure to
report it. Often, the translators are the most attentive reader of a
given text, and if they don't repport the errors they find, nobody will.
3. In any case, remember that the major issue with l10n is that it requieres
several people to cooperate, and that it is very easy to start a flamewar
about small problems because of misunderstanding. So, if you have
problems with your interlocutor, ask for help on the corresponding l10n
mailing list, on debian-i18n, or even on debian-devel (but be aware that
l10n discution very often become flamewar on that list :)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
--
Computers are not intelligent. They only think they are.
