GNOME Bugzilla – Bug 526262
untranslated strings in advanced search
Last modified: 2008-06-27 17:24:51 UTC
tasks view. search -> advanced search -> criteria. "Any Field", "Category" and "% Completed" are untranslated. and /calendar/gui/caltypes.xml contains "Loaction". fixing would be a string change.
same goes for memos and calendars of course
Created attachment 112818 [details] [review] location.patch Location patch. I try to invastigate the rest.
I understend too little about this code to fix the untranslated strings.
It seems the <title>...</title> in those memotypes.xml, tasktypes.xml and caltypes.xml should be set to <_title>...</_title> (underscore at the beginning of the element name), and a little change in evo/filter files where is looking for "title" only to look for "_title" too, and it would start to work. Of course only when translators will do their job too, because these strings will be found as new for translation. Will you do the patch? If so, please add a ChangeLog entry too. Thanks in advance. (Please do one patch, not many small patches.)
(In reply to comment #4) > Of course only when translators will do their job too But they can at least DO their job when the strings are marked for translation. Currently there is no chance to localize it at all. :)
(In reply to comment #4) > It seems the <title>...</title> in those memotypes.xml, tasktypes.xml and > caltypes.xml should be set to <_title>...</_title> (underscore at the beginning > of the element name), and a little change in evo/filter files where is looking > for "title" only to look for "_title" too, and it would start to work. Of > course only when translators will do their job too, because these strings will > be found as new for translation. > > Will you do the patch? I'll try > If so, please add a ChangeLog entry too. Thanks in > advance. > (Please do one patch, not many small patches.) > Shell I include the location.patch in the second patch?
(In reply to comment #5) > But they can at least DO their job when the strings are marked for translation. > Currently there is no chance to localize it at all. :) Not truth. They can add there those strings manually and it will work even for older versions, but I agree, that's more than inconvenient way. :) -------------------------------------------------------------------------------- (In reply to comment #6) > Shell I include the location.patch in the second patch? Please do include it there too and obsolete that old one. Thanks.
mcrha: add them manually? where?
To the .po file? I do not know how it works exactly, but I guess the .po files are generated from sources, and then translated and with some tool transformed to some binary file. So I thought adding there a msgid and msgstr as is expected and regenerate the binary file should work. But that's just my guessing, nothing else, really.
I'll send in a minute a patch. (In reply to comment #7) > (In reply to comment #5) > > But they can at least DO their job when the strings are marked for translation. > > Currently there is no chance to localize it at all. :) > > Not truth. They can add there those strings manually and it will work even for > older versions, but I agree, that's more than inconvenient way. :) > Are you sure? Are the _ macro actually called on title elements? If yes I will remove the additional calles. > > (In reply to comment #6) > > Shell I include the location.patch in the second patch? > > Please do include it there too and obsolete that old one. Thanks. > Ok.
(In reply to comment #9) > To the .po file? I do not know how it works exactly, but I guess the .po files > are generated from sources, and then translated and with some tool transformed > to some binary file. correct so far. > So I thought adding there a msgid and msgstr as is expected and regenerate > the binary file should work. But that's just my guessing, nothing else, > really. that part won't work, because the parser won't find a match. and a translator should never need to take a look at any source code. (In reply to comment #10) > Are you sure? Are the _ macro actually called on title elements? > If yes I will remove the additional calles. iirc we do that also in the plugin xml files so it should work.
Created attachment 112833 [details] [review] Patch including additional gettext calles An patch with additional gettext calles (_title is handled differently then title).
Created attachment 112834 [details] [review] Patch including additional gettext calles Wrong patch - sorry.
Created attachment 112835 [details] [review] Patch including additional gettext calles This should be correct (I hope).
Created attachment 112836 [details] [review] The patch which handles _title and title in the same way This patch should be commited if the _ is already called on title.
(In reply to comment #10) > Are you sure? Are the _ macro actually called on title elements? > If yes I will remove the additional calles. Yes, I'm sure, that's the reason why some of them are translated and some not. So do not do that in the way you did, just do something like if (is "title" || is "_title") {...} no need to localize that, furthermore, the added localize breaks the functionality. Fix this too please: <_title>Description Contains</_title> (should not use two underscores where was one already). --------------------------------------------------------------------------- I'm not sure to which patch I did the comment above. There are too many patches... If you consider the above comment, which one I should review now?
(In reply to comment #16) > (In reply to comment #10) > > Are you sure? Are the _ macro actually called on title elements? > > If yes I will remove the additional calles. > > Yes, I'm sure, that's the reason why some of them are translated and some not. > So do not do that in the way you did, just do something like > if (is "title" || is "_title") {...} Last patch (Attachment #112836 [details]). > no need to localize that, furthermore, the added localize breaks the > functionality. > > Fix this too please: > <_title>Description Contains</_title> > (should not use two underscores where was one already). > Yes - I know. This problem I've solved already and patch with this error is already made obsolete. > --------------------------------------------------------------------------- > I'm not sure to which patch I did the comment above. There are too many > patches... Sorry. > If you consider the above comment, which one I should review now? > The last one (Attachment #112836 [details]).
OK, looks good, you can commit to trunk.
Committed as rev 35689. Thank you Maciej for your patch!