Re: [RFC] l10n survey available
On Sat, Aug 18, 2001 at 06:38:16PM +0200, Michael Bramer wrote:
> On Sat, Aug 18, 2001 at 12:10:15PM +0200, Martin Quinson wrote:
> > On Sat, Aug 18, 2001 at 11:01:32AM +0200, Michael Bramer wrote:
> > > But IMHO the ddts resolve all the translation problems.
> >
> > Not all, but that's better than what was done before. It does not help
> > enough on maintaining, since the translator won't be warned of the need of
> > update.
>
> sorry, but you don't read my announcments, the guide and the faq (and
> you don't support with translations on the ddts :-)
Oh, ok. I do not follow the ddts every day, that's true. So what ?
> The updates does work. See the daily update output on
> http://a.d.o/~grisu/ddts/
What is the 'a', again ?
> > And you add a new format of material to translate. Since translators
> > are not all geek, that can be a problem, and I would prefer if the dtts
> > communicate with translator in po format. Because kbabel, gtranslator and
> > others exists.
>
> This is not a new Format.
> Mail and rfc822 (aka control file format) are not new.
>
> You need not a greek to translat the desccription. Ok, sometimes a new
> translators make mistakes, but the coordinator for his languages get
> all translations as bcc's and he will help. The server help with
> warnings and error messages etc.
Yes, ok, you're right. My point was that it's a new format *for translators*.
And like in the debconf format, nothing is done to prevent the translator
*in the format* to fool around. For example, you can't make a script
checking if the translator mixed the short and the long description.
Splitting them in 2 msgid could allow that (beside of allowing translators
to use tools specially designed for translating).
> > But as I said before, I prefer the dtts as it is now than as it was 6 months
> > ago...
>
> We don't have a ddts 6 months ago. The ddts is only 1-2 months old.
Yes, exactly ! I wanted to say that I'm happy that someone did something
about description translation ;)
> (this web page was like the debconf translation page. The debconf page
> is all by hand, without real scripts etc. If someone translate a
> debconf, he send a mail to _me_ and _I_ change the webpage... not
> nice. This don't work with >6000 description. After a discuss with a
> main debconf translator of a web interface, we (he and myself)
> prefered a mail interface... -> I write the ddts.)
And the ddts may fit the needs for managing translations. That's one part of
the architecture I hope we will be able to build.
> > But what I dream about is the contrary, in fact: I dream about seing all
> > group using the same tools. So, Debian l10n tools would be contributed by
> > others, too.
>
> ok, this is a dream.
>
> start with the reality. :-)
My whole point of view is that I'm tired of seeing any existing group in the
community starting its own set of crude scripts, any program designing its
own i18n format, any l10n program (like kbabel) integrating its own special
features like verificator.
I think it's time to think about merging projects.
I've myself a set of crude scripts. w.d.o/intl/l10n, for example, or scripts
mailling translators of the debian web site when they need to update their
work, and some other to keep a track of who is translating which debconf
template in french. I'm one of the coordinator of the french team for debian
(i translate the po files of dpkg or debconf, for example) and if you search
the archives of lists like -www or -doc (beside of -l10n-french), you'll see
that I'm more active than you seems to think.
> > And because the maintainer delays the translation, I would like to give the
> > translator the ability to commit his changes....
>
> yes. This can we make and without NMU. The translations need this own
> packages. And for this, we don't need a change in the constitution or
> a new kind of person.
Sure it can be done. It was some kind of provocation. You can begin
incorporate Debian Developer which are only translators. Or you can have
some DD MNU'ing around to get the translations in the packages, but I think
some people won't like it. Or you can do what I said, and have several
maintainer per package. One for tech points, and one per language, for
translations. I know it's impossible to change the constituion for that. I
was dreaming about the best solution in my point of view.
> > > to the Packaging issues:
> > > IMHO we should not include all translation in all Packages. A
> > > package with
> > > - all man pages with all >20 translations
> > > - all package description
> > > - with all po-files
[...]
> > > are to big and useless. Nobody can write/read all this translation
> > > and use this...
> > >
> > > The 'orignal' package include only the english man and info pages,
> > > the english description, etc. And we have a usefull co-packages with
> > > only the translated parts (man, info, po-files, REAME, guides).
> > >
> > > With this you need only reconfig apt and you get more languages or
> > > less.
> >
> > Thank you for resuming my text :)
>
> no, this was no resuming. Your text are treat much more.
>
> the point was:
> don't include the translation in the normal packages!
>
> this is only a delay and we don't any advantage with this. Put the
> translation in his own packages and improve the package managment
> (aka apt) and get this packages automagic installed.
You mean also separating source package, or having a source package
generating many binary ones ?
I mean the second way, and I think the first one would be bad, because it
would be difficult to keep packages syncronized. IMHO, of course.
Thanks for your interest.
Bye, Mt.
Reply to: