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

Re: Reasons why package central approach to handling translations may be suboptimal

On Thu, Sep 06, 2001 at 03:42:00PM +0900, Junichi Uekawa wrote:
> I have been reading the DDTS thread, and seeing that it was
> resolving into a "each package should maintain their translation". I
> would like to present what I think may be problematic in that
> approach :
> 1. This results in filing random bugs in BTS in random manner. [snip]

I think there's an answer to this problem: When the maintainer updates
the translations of his package, this should be fully automated.
E.g. just one command

  update-translations --from-mbox <my_mail_archive>

which fishes out the DDTS messages (which are sent in a standard
layout), or, for people lucky enough to be permanently online, an
"update-translations --from-web" command in debian/rules which gets
the translation updates directly from the DDTS server.

So far, *everything* related to a Debian package can be found in the
corresponding source package. I don't think it's a good idea to change

> 2. A package is re-uploaded with translation. There is a package 
> uploaded with one-line changelog saying something like "Merged
> spanish templates". It is a load to autobuilder/ftpmirror/etc. and
> of course manual intervention to rebuild a package means that an
> error occurs, and it does.
> The main problem here is that translation start after the initial
> upload of packageto Debian happens, which means there will be a "-2"
> Debian package which will include the translation, and a "-1" Debian
> package will have no translation.

Yes, that's one of the basic problems. IMHO with the proposed
"override" mechanism via Descriptions-XX.po (or whichever form it is
going to have), this is mostly solved - anyone getting the "-1"
package from testing will already see the translation. People tracking
unstable may or may not see them, depending on how often they update
and on the speed of the translators.

Some people are concerned that their daily update from unstable will
need too much bandwidth because of all those extra uploads. If the
override mechanism works, I see no reason not to have a policy "don't
re-upload if only the translation changed".

> 3. No choice of "I want this locale and not others".

I assume in particular you mean "I prefer this _encoding_"? This is a
point that hasn't been discussed at all so far.

Will there be one description .po file per language in the source
package, or one for all translations? The alternatives here are:

- Supply descriptions in UTF-8, and recode them for the user's current
  encoding on the user's machine. Nice and clean, but requires support
  (possibly quite extensive changes) in dpkg/apt. NB, we _do_not_ need
  full Unicode support in all of Debian for this, just in the tools
  that deal directly with the description data.

- Supply descriptions in UTF-8 and recode them to a default encoding
  that root can configure on each machine. Do the recoding immediately
  after an "apt-get update" or "dpkg -i", so the UTF-8 version is
  never stored on the machine. Might be the way to go for the moment,
  even if it's not ideal. Most importantly, it is upwards-compatible
  with the first solution above.

- Pick one default encoding per language and just assume the user uses
  that encoding. Problematic: Should we ever want to change the
  default encoding, there'll be lots of packages using the old
  encoding, and we'd be stuck with it.

I'm all for at least _supplying_ the translations in UTF-8, even if
they're not stored on the user's machine like that for now. Note that
this does not even mean that the translators need to produce
translations in UTF-8 - the DDTS can recode their work into UTF-8.




  __   _
  |_) /|  Richard Atterer     |  CS student at the Technische  |  GnuPG key:
  | \/¯|  http://atterer.net  |  Universität München, Germany  |  0x888354F7
  ¯ ´` ¯

Attachment: pgpghgMkRq7h4.pgp
Description: PGP signature

Reply to: