Re: [Texmacs-dev] Translations

[David Allouche]

On Thu, Nov 07, 2002 at 06:25:35PM +0100, Joris van der Hoeven wrote:
> 
> Well, let me tell you a few words about this.
> The idea is to translate trees into trees using
> context-based pattern matching.

Thanks. That is interesting.

> First of all, there will be two types of dictionaries:
> dictionaries from one language into another and
> dictionaries from "one language into itself".
> 
> A dictionary rule is of the form
> 
>       (context source dest)
> 
> In fact rules are rather grouped like
> 
>       (context
>         (source dest)
>         ...
>         (source dest))
>
> The context might be something like "menu" or "color-menu".

I guess "menu" would be the default context for menu items, and
"color-menu" would be a more specific context for that particular
menu.

I guess there would also be contexts like "file-dialog", "style".
Right?

I can admit the context would be easy to handle for "file-dialog" and
"style", but how would "menu", "color-menu", etc. integrate with the
scheme menu definitions?


> Both "source" and "dest" are trees with wildcards, like
> 
>       ("tree" "arbre")
>       ((concat "The file '" #x "' does not exist")
>        (concat "Le fichier '" #x "' n'existe pas"))
> 
> Notice that "concat" is also used as a primitive for
> string concatenation. There are two other primitives:
> "translate" and "rewrite". For instance:

I notice this makes edition of translation much more tedious, and
that this gives nothing more than format-string as used by gettext.


>       ((concat "Write text using a " #x " font")
>        (concat "Ecrire du texte en utilisant une police "
>                  (translate #x)))

I do not really see the point in that. The client knows that the
parameter is to be translated, so that kind of thing is naturally
handled with format string.


> The "rewrite" primitive is used for the specification of
> grammar rules for a given language. For instance:
> 
>       ((feminin "gras") "grasse")
>       ((feminin "vert") "verte")
> 
> Then the above rule might become
> 
>         ((concat "Write text using a " #x " font")
>          (concat "Ecrire du texte en utilisant une police "
>                  (rewrite (feminin (translate #x)))))
> 
> The "translate" and "rewrite" primitives take an optional
> argument for changing the context.
> 
> As a final primitive one might add "function", like
> 
>       ((feminin #x) (function french-feminin #x))
> 
> where "french-feminin" is a scheme function which
> automatically computes the feminin form of a masculin word.

That part is the really interesting thing. If I get the idea right, it
is about using the structure of natural language to reduce the number
of translation units.

Essentially that approach would be very good if we were fighting an
exponential growth. But we are not. The amount of translation strings
grows, at most, linearly in time. And if we removed all the unused
translations we will see that growth is even smaller than it appears.

I have no experience in translating TeXmacs, so I have to ask localizers:

  Do you think these factoring tools will be effective in reducing
  the amount of repetitive translation?  Do you think that the added
  complexity is worth the gain? Do you think the gain is worth the
  loss of compatibility with .po files.

And, yes, the Andrey's tool is probably very helpful for Russian, but
it is no match to KBabel (which I have seen at work). The GNOME
praject also certainly have a similar tool...

About what using .po can give, I read the KBabel manual.

- string extraction keep the original file as a comment to provide
  context for the translator and make it easy to fix typos in the
  original strings.

- word which can translate differently are marked with a context
  suffix. Example: "file_menubar", "file_filedialog"

- Translations in other languages can be helpful
   http://docs.kde.org/2.2.2/kdesdk/kbabel/auxiliary.html

By the way, using existing .po translation as a base for translation
not only makes it easier, but it also help improve consistency across
application. So that is not only convenient. That is a plain Good
Thing.

My final remark: localizers are generally non-programmers who want to
help. I do not believe that introducing programmatic abilities in the
translation system will help them. Instead, making it easier for them
to use nice GUI tools will help a lot.

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.