Re: [Texmacs-dev] Translations

[Joris van der Hoeven]

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

I am still thinking on that.
This can either be explicit or implicit.

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

For the examples given here, yes.

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

Not only that: I add structure to the way things are translated.

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

Yes, but at the cost of lesser elegance. Often the amount of translation
strings is kept linear in an artificial way. In real phrases,
you may want to combine several concepts, which get conjugated
as a function of the language. This number of possible combinations
may grow faster than linearly.

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

Being the main localizer of TeXmacs (three languages in addition to
English), I think yes. I also do not think that we loose compatability.
We enhance .po with addional, structured, features.

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

Well, I think that Andrey had a lot of fun developing his tool and
that his tool has proved to be valuable for many people,
and not only for Russian users. In any case we needed a tool
like this in order to reuse older dictionaries.
So you may be a bit more respectful for one of our main developers.

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

Yes, but this can be easily achieved with my scheme too. In any case,
we will have to figure out how to provide such "consistency" for strings
in the scheme files.

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

1: we already have such a tool.
2: 99% of the translation rules will remain easy to understand for
   non-programmers. Only a few tricky rules need more care and
   they will be usually be separated in another file.

I must say that you make me quite tired: you first ask me for explanations.
You then tell me to be frustrated if I do not immediately give them,
although I am clearly entitled not to have time to explain you everything
I say or claim. In fact, at the moment that you say this, there actually
have been explanations. Then you put all your energy in explaining that
what I want is wrong, even though it is clearly a nicer solution from
a technical point of view. All this, while you admit that you are not
a translator yourself, and probably not a specialist on the subject.

I conclude that I am loosing my time with explanations for your
mere curiousity and that I get only negative comments in return.
I recall you that I develop free software for my pleasure and
that I like to innovate whereever possible. Maybe I often reinvent
the wheel, but I am willing to take this risk. Sometimes I loose
some time, but other times I win some. If people are not willing
to make positive and interesting comments, then I prefer not to
waste my time with discussions. In the case of translations,
I could have written 10% of the desired program instead of writing
down all these explanations. We are even compatibile with .po files,
so why rant?