Re: translating clock.schemas.in in gnome-panel



Adam,

Today at 17:10, Adam Weinberger wrote:
>
> If part of the string needs to be immutable, why not only gettext-ize
> parts of the string and then sprintf it? Or am I missing the point?

You're missing the point: .schemas.in files are regular XML files which
are translated indirectly via intltool.

intltool-extract extracts those strings into PO files, and there's no
way to extract translators' comments from them at this time (other
than updating intltool; a simple change, but needs to be done and
agreed upon, with the latter stopping it from being integrated
recently).  Later, intltool-merge extracts translations from PO files
and inserts them into .schemas files, and it must have some knowledge
of the format itself.  So, we've got pretty static files that need
translation, and there's no option to "sprintf (part of) it".

Next, we've got here a value which needs to have different defaults
in different locales (eg. in USA it needs to be "12-hour" and in
Serbia it needs to be "24-hour").  With hardly any translators being
psychic (my advance apologies to any that are), they cannot deduce from
the string itself that it needs to be adjusted in this manner, and not
really translated.  So, they need a guiding comment which will tell
them what is this about.

This is sort of wrong approach to the problem (12/24-hour setting
is present in POSIX locale definitions, inside LC_TIME, not
LC_MESSAGES which are used for PO files), but is currently regarded
as most dependable way (locales are so much harder to update/fix
upstream, and I'm talking out of my own experience).


With me having acquired more knowledge of XML::Parser, I'm about to
claim that the tree-mode it offers *sucks* (and SAX parser is not the
easiest thing around to work with, either), so I'll probably update
intltool to support comments for translators in all XML-like files
soon (with current regex-based parser in intltool-update;
intltool-merge already uses XML::Parser in "tree" mode which
disregards comments).

I'm also planning on campaigning for usage of libxml2 Perl bindings
in intltool if we want true XML support (with a proper XML parser),
since that's The One True Gnome XML library -- that will have many
added benefits as well (better DOM representation), so it's not only
for political reasons.

Cheers,
Danilo



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]