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