Re: Summary (Re: A system for localizing documentation strings)

[Jean-Christophe Helary]

On 28 juil. 07, at 00:16, Jan Djärv wrote:
> Jean-Christophe Helary skrev:
> > On 27 juil. 07, at 18:04, Jan Djärv wrote:
> > > Jason Rumney skrev:
> > > > Jan Djärv wrote:
> > >
> > > We can not guarantee that maintainers of external lisp packages  
> > > will do
> > > anything, regardless of what mechanism Emacs use.  But the point  
> > > is that Emacs
> > > is unlikely to be translated by the translation teams that are  
> > > already outh
> > > there if a completely new mechanism that differs much from  
> > > gettext is adopted.
> > This is preposterous. There are plenty of localization teams that  
> > handle many different processes, source files, translation tools.
>
> I'm sure they are, but within GNU?

What does GNU propose to localization teams ?

A process to deliver an intermediary translation format (PO) and a  
process to put that back inside the code.

The teams must do everything else (ie the actual localization)  
themselves in conditions that sometimes have nothing to do with GNU  
tools.

As I wrote earlier, most localized applications are not applications  
specialized in handling strings. This specificity of emacs should be  
used to ease the whole process.

> > Gettext is far from being the only way to localization. And here I  
> > mean localization as menu items + interface messages +  
> > documentation, where documentation weights much more than all the  
> > other strings combined.
> > Besides, gettext may be good for short sentences (specifically  
> > menu items and short messages) but documentation translation is a  
> > totally different process.
>
> There are longer strings in applications that use gettext than many  
> function documentation strings in elisp.  As for manuals, that is  
> another matter.

Still, most projects will use gettext-like processes even for manuals  
(see po4a from Debian) because the gettext centered localization  
processes have created an ecology of software that prefers to use a  
localization file format _even_ for manual translation work.

The translation functions that would come with the localization  
framework wold address such issues and contribute to facilitate the  
actual localization/translation process that is today barely more  
than text editing in specialized (PO aware) editors. A very  
undeserving task.


Jean-Christophe Helary