On Wed, 2002-04-10 at 19:51, Alex Roitman wrote:
Hi Alex...Hi, Right, but this line is/should only be present if the current po file is fresh and non-translated!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: <[po-header]> Note the #, fuzzy line before msgid "". 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.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. 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? 
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 laEmpty 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. ). 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.
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?It seems that gtranslator (1) consistently removes this FUZZY mark from header on Save, 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?and (2) formats po into gmo using -f flag, thereby including this crap-for-the user into the output. 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"));And I would say, we're not using the -f flag, not? 
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!Does it make sense to, maybe, (1) do not overwrite fuzzy lines in comments, 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(2) allow to control presense/absense of "-f" formatting flag from preferences,
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.and also (3) control where the output ends up? Presently, it seems to write the output.gmo into $HOME, but I might have different ideas as to where I want to place the result. 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... gtranslator is the solutionI'd be happy to learn that there's another solution for (1) and (2).
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.Although, it would be nice to have (3) anyway :-)
|