Re: [RFC] l10n survey available
On Sat, Aug 18, 2001 at 10:17:36PM +0200, Michael Bramer wrote:
> > That's why converting all material to po files could be a good point. The
> > program in charge of converting pkg desc to po files could take care of
> > isolating the different elements, making sure the translator can't mix them.
>
> But with po-files you have other problems:
> - the 'space-dot-char problem'
> - the 'to long short description problme'
- Split the paragraph in separate msgid, and the translator don't have to see
it.
- Make a rule of the verificator which check the length of the description
> > > 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?
> >
> > You won't do that this way. The _() notation is to help the extractor to
> > find which part of the program it has to extract while building the po file.
> > In C, there is this line somewhere:
> >
> > #define _(text) gettext(text)
> >
> > So, for the C compiler, the two functions are identical. But the first one
> > is used at compilation time to build the po file, and the second is used at
> > execution time to actually translate the text.
>
> I know that. But this was not the question...
>
> > For example, in glade, the interface is in a xml file, and the extractor
> > can't handle such files. So gnome guys have tool to make some fake C files,
> > containing a list of:
> >
> > char *dummy= _(TextToTranslate);
> >
> > These files are never compiled, but the extractor use them to put the needed
> > lines in po file. Then translation, then compilation. Then, at runtime,
> > somewhere in glade, there is something like
> >
> > char *title = read_title_from_xml_file();
> > gettext(title);
> >
> > The extractor will not use it, since it's not the _() form, but the runtime
> > mechanism will find the translation of the string pointed by title.
> >
> >
> > Well, I'll make a picture of the architecture. Just wait one hour, I run
> > xfig...
>
> the question was:
> if I put the translation in a compiled po-file (the mo-file ?), and
> if dpkg use _(.*) in its output procedure (with '.*' is not a static
> text), have we a translated output?
That's the question I tried to answer :)
If you use gettext(variable), it works (as explained above). If you use _(),
you'll put the extrator into trouble, but yes, the text will be searched at
execution time.
The main problem is that AFAIK, gettext search in only 1 textual domain.
So, if you do it so, it will search in the translations *of dpkg itself*. We
need a way to switch between domains (dpkg's and descriptions one). I'll
check with gettext maintainer if there is a way to solve it.
> > Before to start any new project, I would like to see if it's possible to
> > make an architecture in which I could insert the work from other people. If
> > I say I'm tired of seeing anyone reinventing the wheel, I'm not allowed to
> > do the same mistake ;)
>
> if your architecture better as the ddts (and of course open source,
> etc), I will witch the ddts to your architecture...
I don't want you to switch completely, but to integrate, when possible. ddts
could be the manager in the middle of the picture, for example.
> > > 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' :-)
> >
> > But I reviewed quite a lot of them, since we've made a policy between french
> > translators: any translation should be send to -l10n-french for review
> > before being submitted to the ddts. The problem is that French is a really
> > hard language to write. Even french native speaker offen make mistakes while
> > writing. We need such a review process...
>
> this is your problem. (Now I know, why the french are so slow... )
Review slows down the process, but increase the resulting quality ;)
> But is this not better:
> - the server send all french translation to the -l10n-french list
> and the can check this...
> (I know frech is a hard language, but I hope a french native
> speaker don't make to much mistakes and you don't need fix all
> translations...)
Look at the -l10n-french archive. The description I used to do my fake one
generated a 20 mails long thread of review...
Yes, please, mail any description you put in the DB to the list, too.
Because I see 14 french translators, and not that much use our reviewing
policy... The best would be to group the translation to have at most one
mail per day (to not flood the list more than it is already).
BTW, I just updated my page to add a picture of my architecture.
Bye, Mt.
Reply to: