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

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


I think .po files are assumed to have an empty id for translation
Many tools use this data. For instance msgfmt uses the charset data to
determine the charset. I think it would be a bad idea too change this.

Yes. I don't think that's the one causing the issue.

In addition, I think one really needs some documentation regarding the
translations, i.e. what to translate and what not.
I'd like to see some general information e.g. for

msgid  "&Blank Tool;Activate the blank tool;Blank"
msgid "&About Xara XS;Information about Xara XS ;AboutOp"
msgid "XYZxyz"

What to translate and what not? And what means the third entry after the

Yes indeed. In answer to your specific question, the first is
the menu entry, the second the help entry, and the third the
OpToken of the OpDescriptor it invokes (i.e. the internal command
it is attached to). Do not translate the third one :-)

In C programs, comments which appear just before the text are included
in the .po file. Example:
Using the xrc files, one cannot do this directly. Could one update the
scripts to include such a string by using
    <label>XYZxyz<!-- static text, don't change--></label>
and write then in the .po file:
#. static text, don't change
#: simon-strings.xrc
msgid "XYZxyz"

or at least the "#: <file>" part?

With xrc, we generate using wxrc. It would be nice if at least put the
object name of the thing it was translating in. We just use wxrc and it
doesn't currently seem to do that. I either need to rewrite wxrc in
perl (tempting given how much grief we've had with it) or someone needs
to fix up the wxrc source to emit comments. I would have thought the
label name would be the minimum useful thing. The source file line
number is sadly not useful as we feed it a pipe consisting of
preprocessed and precombined other xrc files (arguably we could not do
this if we rewrote it). The most useful thing here would be the
nested list of object names, i.e.
which would transform an anonymous name (the latter) into context.
I think wxrc is in a bit of disrepair and given we use so little
of it, and given it causes us such problems (see long bad history
on gentoo) it may be the easiest thing is to rewrite the lot in
perl to do just this; it would probably speed things up too.

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.

In both cases, you would then be able to find them in the source using
  Scripts/all.sh | xargs fgrep IDS_FOOBAR_TOOL_ERROR_STRING
and even for someone can't read/write C++ that might at least help
identify where a string appears.

If that would be useful, can you file a bug for me please? This working
is all conditional upon xgettext transparently passing through comments
as you describe. I am not going to rewrite xgettext!