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

l10n infrastructure: using a big DB instead of packages?

On Fri, Jun 04, 2004 at 11:32:55PM +0200, Nikolai Prokoschenko wrote:
> On Fri, Jun 04, 2004 at 01:29:19PM -0400, kcr@debian.org wrote:
> > [Actually, this has been causing me to conclude that we probably need a
> > mechanism whereby translators can cause new translations to appear
> > outside of the structure of the "package" itself.
> This seems to me like an interesting idea considering a debian-l10n
> framework. It would be interesting to see some script called update-l10n
> (just like update-flashplugin and update-msttcorefonts), which would
> fetch the updated translations. I see following improvements:
> - Translations are not a part of the package anymore, so they can be a)
>   worked on and b) released independently

They can already be worked on independently. But yes, under some assumtion,
it would be good if it could be released independently. 

> - The system could get more and more translated, even a stable one -
>   imagine a computer class somewhere in India, which runs stable, has been
>   completely English at the moment of installation and gets more and more
>   translated after some Hindi translators have been found.
> - We will have no l10n-uploads anymore - I'm sitting on a 2 MBit/s
>   DSL-channel and I'm sometimes really pissed off by my daily sid update
>   logs, which tell me that some 10-MiB package has been only downloaded to
>   update some debconf templates for the languages I never use anyway.

You're proposing a wrong solution to a real problem. It you're sick of
massive downloads changing almost nothing within the package, the solution
is not to dig in the package paradigm. It's to implement a download solution
featuring rsync or diff mecanisms. What will you do when people will start
fixing typos in copyright files ? Will you propose to remove those files
from the dpkg authority as well ?

> - Flexibility considering installed languages - I can choose the languages
>   I want (/me thinks of kde-i18n-* - NO, I DO NOT want *such* bundled
>   packages, it must be more flexible).

Yes this package is the devil. But there are other solutions.

> Drawbacks I see at the moment (Christian will most probably see thousands
> more ;)):
> - Organization. This method would presume that all translations are
>   handled in the same way, most probably with some kind of big database of
>   strings (I have some ideas for this database which I'll post later on,
>   so it's not really a drawback to me ;))

I'm not sure centralization is good (or even possible) when you speak of
free softwares as a whole, IMHO.

> - Distribution: how do we distribute "initial" translations (e.g. on a CD)
>   and how do we update them effectively? What if no net access is given?
>   (solvable)
> - If we integrate upstream templates (i.e. program translations), how do
>   we synchronise with upstream? (tricky)

Mmm. I'm almost tempted to say "impossible" instead.

Ok, I hate myself now, critizing your vision of a big infrastructure for
translations. That's my dream, too. But I think it would be very wrong to
handle the translation in the back of packagers and dpkg.

In short, I think it would be really great to have a big database of all
translations in Debian (native or from upstream). But it should be
distributed to users as part of the regular debian packages. If you really
want, you can make some sort of add-on packages diverting the po files from
the regular packages, but I personally see those as temporary solution.

Anyway, let's work on how to build this big l10n database. Then, you'll work
on a out-of-band way to distribute the translations, and I'll work on how to
get those into the package smoothly. What really matters here is to let the
translators do their job as easily as possible.

Did you had a look at the code I commited to the debian-l10n cvs ? That's
the package checker script feeding w.d.o/intl/l10n (and some friends). It
should be possible to let it run on a box and commit the data and material
it extracts from packages.

The main issue is to deal automatically with conflict between translator
changes and packager ones. That's a real show stopper to our big DB dream...

Bye, Mt.

For every complex problem there is a solution which is simple, neat and wrong.

Attachment: signature.asc
Description: Digital signature

Reply to: