Re: [Texmacs-dev] Translations

[Joris van der Hoeven]

> I concur with the initial poster (btw, could you use the standard "on
> xxxx, yyy wrote" header when replying?)
> 
> The translation dictionnaries are WAY too big, and there is NO
> separation whatsoever between GUI translations, style translatian and
> since 1.0.0.20 help section titles translations (actually help menu
> entries).

I already told you that this separation will be done once that
plugins are implemented in a better way.

> That can cause some confusion when trying to make translations because
> one need to know the context, and that makes it very difficult to make
> partial translations (just the styles, just the doc, just the GUI).
> One may may argue that no translation is better than a partial
> translation. But in any case an "orderly" partial translation (only
> style, or only GUI) is surely better than a messy partial translation
> (the 200 first items in the dictionnary).
> 
> Moreover, there is no way to dismiss dictionnary entries which are no
> longer needed because the corresponding GUI items have been renamed.

Well, such entries could be dismissed.
Who wants to make up the list of those entries?
You might want to use "strings texmacs.bin" and
write an automatic analyzer of scheme menus.

> But the really important point here (there have been some discussion
> on #texmacs) is that the "File" menu and the "File" label in the
> get-file dialog must not be translated to the same word in Swedish.

I told you 100 times that this will be changed as soon as
I have time to implement a tree-based translation scheme
(a couple of days of work).

> Also, the current translation scheme hardwires the syntactic structure
> of phrases and mix thi sin the code. That is very bad. Actually, the
> syntactic structure must be provided by the translation, and the code
> should only provide the variable part of the message using snprintf(3).

Yes: tree-based translations (101-th time).

> I do not intend to make the usual rant "we should use gettext in order
> to leverage numerous existing translation support tools, exploit the
> .po corpus of free desktop project and not reinvent the wheel one more
> time"... well... I just did.

If you do not intend to rant, then please don't.

With Andrey Grozin's tool, we *are* already able to use the .po corpus.
So if you want to fill out missing translations for new languages,
then please go ahead!

>From a technical point of view, it is clear that .po files are a bad
system for the future, because the only "grammar rules" which you
can provide are string concatenations at predefined places.
What one really needs is a tree-based tool.