Re: [Gtranslator-devel] header problems in po-files

On Wed, 2002-04-10 at 19:51, Alex Roitman wrote:
Hi Alex...
I am recently engaged in translation of po-files for a couple of projects.
A problem I have is this: a header of po file, as I presently  understand it,
stores info about translator, project, copyright, etc, as a comment (lines marked #).
It is followed by empty msgid string and a msgstr string with standartized info, like this:
Note the 
   #, fuzzy 
line before msgid "".
Right, but this line is/should only be present if the current po file is fresh and non-translated!
I have to mannually add it after each save, because otherwise all empty strings in
the source code (msgid "") are getting translated into the bunch of irrelevant (for the user)
strings with translator's info.
Sure? That shouldn't be AFAICJ (=as far as I can judge) because the first msgid + msgstr pair shouldn't be taken as a translation information by gettext. It was told to me that it doesn't do so and therefore we do remove the fuzzy comment on it always on save.

If it would be translated we woulnd't have some problems we lately had with some character information in gtranslator's sources, so I would strongly think that I'm right in this point or why have I spent time on the solution we're currently using? ;-)
Empty strings are routinely found in the source code. Maybe they should not be marked as translatable ones, but I guess the developers might want to keep them this way
for their reasons, who knows.
They shouldn't do so as the empty string is reserved for gettext's own purposes -- this is a quite big fault on their side (not that I would have done the same mistake some months ago la la la la ;-)). Which projects are using such empty strings? If they haven't got any special meaning for the source then these strings should be kept non-translatable of course.
It seems that gtranslator (1) consistently removes this FUZZY mark from header on Save,
Yes, this is intentionally so as a translated po file shall not contain the #, fuzzy comment line -- why you might want to ask? Well, gettext compiles it as a po file without any translation information if the po file still contains the #, fuzzy comment line in the header and I don't think it is our intention to do translation work without any visible output, not?
and (2) formats po into gmo using -f flag, thereby including this crap-for-the user
into the output.
gtranslator doesn't use the -f flag for msgfmt any time and this output should never go in; where did you get the impression that gtranslator uses the -f flag?

Our source code just contains following lines containing msgfmt:
dialogs.c:901:  dialog = gtranslator_utils_error_dialog(_("An error occurred while msgfmt was executed:\n"));
formats.c:45:    *  this should work as we do "simply" use msgfmt.
formats.c:60:           "msgstr \"%s\"' > '%s' | msgfmt -c '%s' -o /dev/null 2>/dev/null",
parse.c:1142:    * Check if msgfmt is available on the system.
parse.c:1144:   if(!gnome_is_program_in_path("msgfmt"))
parse.c:1146:           gtranslator_utils_error_dialog(_("Sorry, msgfmt isn't available on your system!"));
parse.c:1163:   cmd = g_strdup_printf("msgfmt -v -c -o '%s' '%s' > '%s' 2>&1",
save.c:97:      if(!gtranslator_utils_check_program("msgfmt", 1))
save.c:109:     cmd=g_strdup_printf("msgfmt '%s' -o '%s'"
And I would say, we're not using the -f flag, not? :-)
Does it make sense to, maybe, (1) do not overwrite fuzzy lines in comments,
Nope, as pointed out previously, this would make the whole po file senseless as no translation data would be transformed to the compiled (g)mo file!
(2) allow to control presense/absense of "-f" formatting flag from preferences,
We don't use the -f flag in gtranslator; maybe you set an alias to msgfmt so that gtranslator's own msgfmt calls are converted to msgfmt -f by the shell, may that be? But we do not use the -f flag, really not, believe me :-)
and also (3) control where the output ends up?
Presently, it seems to write the into $HOME, but I might have different
ideas as to where I want to place the result.
Erhm, not fully right. The compiled gmo file is put into the same directory as the po file, ergo if you opened the po file ~/po.d/tr.po it will put a compiled gmo file into ~/po.d/<PROJECT>.gmo so I would say, that it's not that bad.

If you opened a po file in $HOME, it will surely also put the gmo file there; or wasn't this the case? If so, it might have to do with permissions...
I'd be happy to learn that there's another solution for (1) and (2).
gtranslator is the solution :-)
Although, it would be nice to have (3) anyway :-)
Heh, well, I think the way to put the compiled gmo file into the same dir as the po file it's originating from is Ok.
<([ Fatih Demir / kabalak / kabalak gtranslator org ])>
<([ ICQ 64241161 / fdemir2 ix urz uni-heidelberg de ])>
<([ Studying Biology @ the University of Heidelberg ])>

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