GNOME Bugzilla – Bug 549374
unclear strings
Last modified: 2008-12-14 09:29:41 UTC
Some unclear strings that need improvements or annotations for translators all "gtk-*" must not be translatable. e.g. ../plugins/git/anjuta-git.glade.h:83,84,85 ../plugins/git/anjuta-git.glade.h:33 "Add signed off by line" ../plugins/git/anjuta-git.glade.h:35 "Append fetch data" ../plugins/git/anjuta-git.glade.h:36 "Author/Grep"
Created attachment 117388 [details] [review] partial fix
Created attachment 117420 [details] [review] partial fix 2 mark some lines for translation
Created attachment 117425 [details] [review] update strings
Comment on attachment 117425 [details] [review] update strings The patch removes a lot of "gtk-*" translatable strings which is good. It also adds few new translatable (?). However this part seems wrong to me g_object_set (G_OBJECT (action), - "label", label, - "tooltip", tooltip, + "label", _(label), + "tooltip", _(tooltip), Also it does not address the problem of previously mentioned unclear strings.
> Also it does not address the problem of previously mentioned unclear strings. Yes. It's partial fix. I think it's unessential issue for filling a bug. It's only need add annotations for some lines to my patch.
(In reply to comment #0) > ../plugins/git/anjuta-git.glade.h:33 > "Add signed off by line" A signed off by line is something git adds to the end of a commit message that indicates that a patch passes your scrutiny as you commit it to your git tree. For example, if I apply a patch from someone else and ask git for a signed off by line, it would add "Signed off by James Liggett <jrliggett@cox.net>" to the end of the commit log. It's also possible that the patch could have other signoff lines before I get to it. In effect, these lines are a record of who reviewed a patch. To see this practice in action, you might want to check out Linux's git tree at kernel.org. > > ../plugins/git/anjuta-git.glade.h:35 > "Append fetch data" Normally when you fetch new objects from a remote branch you're tracking, git overwrites the data from the last fetch. With this option, data will be appended to the previous infofmation, preserving it if the iser should need it. > > ../plugins/git/anjuta-git.glade.h:36 > "Author/Grep" "Author" means search for commits whose author matches tne given grep expression. "Grep" searches through commit logs and patches. >
Committed after fixing the breakpoint issue mentioned by Christian. Is it possible to add context to glade files so we can make the information from comment #6 available for everyone?
*** Bug 552157 has been marked as a duplicate of this bug. ***
spotted another one ../plugins/tools/tool.c:81 "Same than output" Found this Version 2.6.1 (Oct 12 2004) * Support "translatable", "context" and "comments" attributes for text properties to help with translation. but no idea how to mark glade attributes
(In reply to comment #9) > spotted another one > ../plugins/tools/tool.c:81 > "Same than output" It means that the message send to the error stream (stderr) should be send to the same destination than the output stream.
(In reply to comment #10) > (In reply to comment #9) > > spotted another one > > ../plugins/tools/tool.c:81 > > "Same than output" > > It means that the message send to the error stream (stderr) should be send to > the same destination than the output stream. > Should it be better written as 'Same as output' or 'Same as standard output'?
"Same as output" is definitely better and proper English. 'than' is used for comparisons only - e.g. 'smaller than foo'
Sorry for my bad English. I have fixed the "Same as output" message in the tools plugin. Is there some else to do in this bug ?
Feel free to add James' comments as translator comments, they are excellent hints. Regarding the original problem I am closing this report now, thanks.
Ok, thanks. It's possible to add translator comments in glade files using the the comments attributes. I have added James' comments.