Re: [RFC] l10n survey available
On Sat, Aug 18, 2001 at 08:37:39PM +0200, Michael Bramer wrote:
> 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:
> > 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.)
Yes, but have a look about this (fake) description:
-------------------------------------------------
# this description is from:
db/desc/g/gnome-libs-data/0031054738f5014424a24efb539d610a
Description: Data for Gnome libraries
Gnome is the "GNU Network Object Model Environment"
.
It is a project to build a complete, user-friendly desktop based
[..]
Description-fr: Donnes pour
les bibliothèques Gnome
Gnome est un acronyme pour "GNU Network Object Model Environment"
.
C'est un projet qui vise construire un bureau complet, convivial, et
[...]
For dpkg and others, "les bibliothèques gnome" is part of the long
description, and the short one is only "Données pour". In fact, both part
belong to the short desc. Will your server detect such problem ?
Note: there is the same problem with debconf, for example.
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.
> 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.
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...
> > 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.
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 ;)
> 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...
> > 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're right. I also came to this conclusion. The easiest way to achive our
goal is to have a server which can manage the translation, and publish it to
the users. (in the sense explained in my page)
Good. Now that we agree about the goal, how to do it ? Did you look at the
end of my document, about the architecture ? What do you (and others) think
about that ?
Thanks, Mt.
Reply to: