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

Re: [RFC] l10n survey available



On Sat, Aug 18, 2001 at 07:49:42PM +0200, Martin Quinson wrote:
> 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 ?

no problem. But if you say "Not all, ...", you should check it...
:-)

> > The updates does work. See the daily update output on
> > http://a.d.o/~grisu/ddts/
> 
> What is the 'a', again ?

auric.debian.org
sorry.

> > 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).

sorry, but i don't understand.

(fyi:
  in the ddts every part (section in the long description and the
  short description are saved in a db and the whole description is
  saved in a db.)

> > > 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.

yes, this is a problem

I don't understand gettext really.

one question:
dpkg has the description of the packages in a database. Can I make a
po file with the information in the ddts and patch the output
procedure from dpkg like 'printf _("%s")' and I have a translated
output. Or work gettext only with static textes?

> I think it's time to think about merging projects.

yes. I like this. but start with a little project. If your service ok,
others will move to it.

> 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.

oh, I believe this.

I only say, that you don't translated description with the ddts and
you don't know the ddts. This is not really a problem. Others have the
same 'problem' :-)

> 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.

IMHO the best solution is a extra package with the translation.

a Package with all translations is to big and useless.
  
> > 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 ? 

yes, I mean really separating packages, with own source, own
maintainer, etc.

> 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.

no, this is the job of your server.

This extra packages are not made by hand. Your server get the new
packages after a upload, make the new po files, the new man pages, the
new info pages (new aka translated) and make the new package(s).

If the maintainer and/or the upstream make changes, the server send
mails/... to the translators and wait for new translations. If the
server get a (or some) translation(s), it make a new package...

Like the ddts with the packages files.


you understand?

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger grisu@db.debian.org  -- Linux Sysadmin   -- Use Debian Linux
"Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
 die anderen sind einfach von sich aus unlogisch." -- Anselm Lingnau 

Attachment: pgpcTGO0ObhJW.pgp
Description: PGP signature


Reply to: