A few questions about UI strings
Frederik Schwarzer
schwarzerf at gmail.com
Sun Apr 12 20:38:31 UTC 2009
On Sunday 12 April 2009 02:03:52 Andreas Pakulat wrote:
> On 11.04.09 18:57:05, Frederik Schwarzer wrote:
> > ====
> > kdevelop/languages/cpp/parser/rpp/pp-engine.cpp
> > "expected ``:'' = %1"
> >
> > Messages like these should have a context to make it possible to translate them.
>
> In this case I think only the "expected" should be translatable anyway,
> the rest is actual parser output and should be printed verbatim.
The word "expected" alone is hard to translate. Please consider using context
here as well and maybe put the word in a complete sentence there.
> > In general you should use contexts (i18nc()) way more often.
>
> Yes, problem is that the developer writing the text actually knows quite
> well how he would translate it into his own language (if different from
> english). So he might not be aware that a context is needed, not to
> mention that we easily forget that the other 99% of world population
> have no clue about programming :)
Yes, that's why I wrote http://looksblo.wordpress.com/2009/04/01/translation-is-the-art-of-failure-or-what-makes-our-lifes-hard/ :D
> > ====
> > kdevelop/languages/cpp/veritas/uutcontextaction.cpp
> > "Generate Unit Under Test"
> >
> > Another candidate for some context
>
> Hmm, why? Though, again I'd say only the first word needs translation.
> The rest is a standard term within the area of unit-testing :) Should we
> change such things to
> i18n("Generate")+" Unit Under Test", or rather use
No. For German it is common to leave such terms but there are countries
that are more ... proud of their language or languages with different
writings (e.g. Japanese uses Hiragana and Katakana signs to transcribe english
words. And even in German there might be a proper german term in the future, like
"Entwurfsmuster" for "Design Pattern".
Every user-visible string has to be translatable, even if it seems reasonable to
not translate it.
> > ====
> > "If this option is set, the Document View will organize documents\n
> > by their mimetype. If this option is not set, the Document View will
> > not\n
> > organize the open documents by type."
> >
> > The second sentence ist not needed. Please do not over-document this kind of
> > highly understandable features.
>
> Feel free to remove.
Done.
> > ====
> > Could "Trolltech" be replaced by "Nokia" or is it ok to be as is?
>
> Are you talking about copyrights? If so, then the answer is: I don't
> know, please ask a KDE lawyer - or somebody more familiar with
> copyrights. We did copy some code from Qt, but AFAIK that was all way
> before Nokia took over and changed the company name. So I'm not sure
> what the right thing is.
Yes, I mean in the about dialog info. No idea either, was just curious.
If you copied code, you know where you copied it from. >=4.4.3 would be Nokia.
Anyway, minor issue. :)
> > ====
> > kdevelop/formatters/indent_plugin.cpp
> > "Home Page: <a href=\"http://www.gnu.org/software/indent/\">http://www.gnu.org/software/indent</a>/"
> >
> > What is the point of using the trailing slash like that?
>
> Typo I think.
Fixed
> > ====
> > kdevelop/formatters/astyle_preferences.ui
> > "Break bl&ocks all"
>
> Actually had to lookup what it does in the code, not really god huh? And
> then I needed to lookup the option in man astyle.
Good to see that I am not the only one struggling with this kind of stuff. :)
> Ok, here's what it does, additionally to "Break blocks" (which inserts
> newlines between unrelated blocks, for example between two class
> declarations), "Break Blocks All" adds newlines also around closing
> headers, i.e. around the "catch" for a try/catch, or the "else" for an
> if/else.
>
> So yes, "Break all blocks" is better, I think this comes from the
> original astyle api/manpage which lists "--break-blocks=all".
I leave that to you, since it is more than a typo. :)
Thank you for all the explanations, also to the other responders. It helped a lot
in understanding these strings. There will be more questions in the future. :)
Regards
Regards
More information about the KDevelop-devel
mailing list