Iwan Davies wrote:
[...]
> I'm thinking particularly of problems I've experienced in the past in
> various localisation projects, where, for example, the phrases "von" and
> "bis" have been reused in different contexts wth represent different
> meanings ("von Datum"/"bis Datum" and "von Uhrzeit"/"bis Uhrzeit"). In
> French, for example, the first "von"/"bis" would be translated
> "du"/"jusqu'au" and the second "de"/"jusqu'?".
>
> In English there is no problem in this particular example, but another
> situation could see the German use the same noun as a command an an option
> setting, whereas English would require the command to be translated as an
> imperative and the setting as a noun. The point is, the plugin developer
> has no way of knowing how reuse of strings (and duplicate use of string
> IDs) will affect the quality of the translation, so the safest approach is
> to assign each string a (G)UID. Incorporating the plugin name in this UID
> ensures it is globally unique for vdr. On the other hand, judicious use of
> the tag system in vdr would have the same effect, as long as you could be
> sure that each tag is unique and none are reused.
This kind of problem is taken care of at present in VDR's i18n.c by
preceding such pharases by an arbitrary string describing the context in
which it is used, separated by a character chosen by Klaus, '$' from the
actual english string. In that case, translations may be different and
are also identified properly, and everything before the '$' character is
ignored. But as you said, a developer may anticipate such situations,
but cannot do this for all cases and all languages that may join the
list, so there will be feedback from users who notice some bad sounding
translation in a certain context, and it will be fixed by splitting that
english strings by the scheme already used by Klaus. And this shouldn't
change if gettext will ever be used.
BTW, while writing a plugin only meant for developers, which extracts
all phrases known at present in VDR[*] and generates po-Files for all
the known languages at present, after loading the po-files in poEdit, I
noticed that there are 5 duplicate strings, which even in the classical
concept are redundant, one of them never gets used, but that will be
another posting.
Basicly I'm close to trying gettext i18n, will keep you updated, I hope
this weekend.
Lucian
[*] ...and as a next step, from any loaded plugin, so the old
translations are already in the gettext world. Anyway, if plugin devs
will ever follow this, and they have to test their plugins anyway, I'm
seeing no problem with doing this extraction at runtime instead of
parsing the source files). The po-files are gnerated with all the
message IDs and their translations and even with the "note
leading/trailing blanks, singular/plural" comments, header information
with translation authors for VDR (for plugins I think I will assume for
the respective languages the same translators as in VDR, if a
translation is available).
This way we will have up-to-date po-files, in sync with the "classic"
VDR phrases anytime (and if) the switch to gettext will be ever done, as
in the mean time updates to the "classic" translations may still come.
