Re: [XaraXtreme-dev] Blank msgids in po file

[Tobias Burnus <burnus@xxxxxxxx>]

Hi all, hi Alex,

I have one additional question, before I come to my "translation
comments in .pot files" issue.

Under Windows, dialogs etc. are typically non-resizable and have a
pixel-precise setting of all elements.
Under Unix/Linux dialogs are usually stretchable/resizable and the
elements are only relatively placed; thus changing the font or
the text does not yield to clipping (or at least resizing the window
allows to see the unclipped version).

Under Windows, the resource file for each language contains the whole
information, including the pixel size.
However, using the unix-like .po files with XaraLX dialogs (which are
mostly not resizable; e.g. the color dialog is), causes strings to be
clipped. As German strings often tend to be larger than English ones,
this is a problem. But at least on my system the "File|Page Options..."
-> "General" dialog has also a clipped string in English: "Make groups
be transparent as a whc",
"Save settings on ex", "Current layer always visible and editab".
Also: Tune-ups: "Automati"; View: "Automatic scroll to selected colou", etc.

How should this be tackled?

Alex Bligh wrote:
>> msgid  "&Blank Tool;Activate the blank tool;Blank"
>> msgid "&About Xara XS;Information about Xara XS ;AboutOp"
>> msgid "CAMELOT_BUTTONBAR"
>> msgid "XYZxyz"
>> What to translate and what not? And what means the third entry after the
>> ";"?
> Do not translate the third one :-)
One probably shouldn't translate "CAMELOT_BUTTONBAR" either ;)
Actually, one should try (if easily possible) to exclude strings which
should not be changed.

> But it's not just generated from the xrc. Some bits are generated from
> the string table files. I know these /look/ like xrc files (the
> files that are xxxx-strings.xrc) but they actually go through a
> slightly different resource route these days. These could be relatively
> easily prefixed by the name of the string token in question (e.g.
> "#IDS_FOOBAR_TOOL_ERROR_STRING').
>
> If that would be useful, can you file a bug for me please?
I think it is. I filled the bug #1155. Especially for short or obscure
strings it helps finding them.

> This working is all conditional upon xgettext transparently passing
> through comments
> as you describe. I am not going to rewrite xgettext!
Well, xgettext creates even such comments as one can see here:
--------<some c file>-------------
   /* please translate this*/
   /* tc: another line */
   printf( gettext( "Hello, world!\n" ) );
---------------------------------------
~> xgettext -c ....  # the -c is needed
~> tail -n > tail -n 6 hello.pot
#. please translate this
#. tc: another line
#: hello.c:3
#, c-format
msgid "Hello, world!\n"
msgstr ""
--------------------------------------
Using --add-comments=tc would only leave the "#. tc: another line"
automatic comment.

As the "#." (note the dot after the hash) is generated by xgettext it is
surely supported by msgmerge, msginit etc.

Tobias