Version: (using Devel) Installed from: Compiled sources The translations of Objectnames are not displayed at runtime. Do a wcgrep classNameTr kdeedu/step/ to find all messages, where the parameter %1 is not replaced with the translated objekt name. It is impossible to provide a proper translation for the message "Click on the scene to create a %1" In German I need tree different translation of this string to provide a gramatically correkt german sentence for the different objects. Other languages will even need more than three different translations. Same applies to all these messages: worldgraphics.cc:64: i18n("Click on the scene to create a %1", classNameTr())); worldgraphics.cc:91: i18n("%1 named '%2' created", classNameTr(), _item->name()), worldgraphics.cc:107: "then drag and release it to position the second end", classNameTr())); worldgraphics.cc:110: i18n("Click on the scene to create a %1", classNameTr())); worldgraphics.cc:136: i18n("Release left mouse button to position second end of the %1", classNameTr())); worldgraphics.cc:140: i18n("%1 named '%2' created", classNameTr(), _item->name()), worldgraphics.cc:172: i18n("%1 named '%2' created", classNameTr(), _item->name()), worldmodel.cc:691: return i18n("%1: %2", formatName(object), object->metaObject()->classNameTr()); gasgraphics.cc:45: i18n("Press left mouse button to position\ntop left corner of a region for %1", classNameTr())); gasgraphics.cc:73: i18n("Move mouse and release left mouse button to position\nbottom right corner of the region for %1", classNameTr())); gasgraphics.cc:108: i18n("%1 named '%2' created", classNameTr(), _item->name()), polygongraphics.cc:150: i18n("Press left mouse button to position a center of a %1", classNameTr())); polygongraphics.cc:170: i18n("Move mouse and release left mouse button to define a radius of the %1", classNameTr())); polygongraphics.cc:196: i18n("%1 named '%2' created", classNameTr(), _item->name()), polygongraphics.cc:274: i18n("Press left mouse button to position\ntop left corner of a %1", classNameTr())); polygongraphics.cc:295: i18n("Move mouse and release left mouse button to position\nbottom right corner of the %1", classNameTr())); polygongraphics.cc:325: i18n("%1 named '%2' created", classNameTr(), _item->name()), polygongraphics.cc:418: i18n("Click on the scene to create a first vertex of %1", classNameTr())); polygongraphics.cc:479: i18n("%1 named '%2' created", classNameTr(), _item->name()), Parameter %2 is untranslatable here. Solution: one message for each object typ without parameter %1 No translation of the parameter %1 here in "Contex Info": infobrowser.cc:182: + i18n("Documentation for %1 not available. ", className) In "Properties" no localized number format, the translation of the units is not used here. In "World" and "Undo history" window the translation of names of the objects (eg disk1 - should be in German Scheibe1) is not displayed. Same for the tip displayed when hovering an objekt with the mouse pointer.
SVN commit 920387 by ksvladimir: CCBUG: 181598 i18n bugfix. M +2 -1 infobrowser.cc WebSVN link: http://websvn.kde.org/?view=rev&revision=920387
Hm, its not easy to fix. The %1 in most of these messages is really a variable, your solution requires duplicating lots of code. I'll think about it... Object name (like disk1) can't be translated since it is defined by the user. However when examples and tutorials will be translatable it won't be a big problem. Numbers are not translated because they are shown in scientific format (i.e. 1234567 => 1.235e+06). KLocale is not able to localize number in this format and I think that the format itself is international, isn't it ? Unit names are not translated because these names should be parsable by libqalculate. libqalculate has a very limited support for translating unit names, and actual translations are available only for a few languages.
> Hm, its not easy to fix. The %1 in most of these messages is really a > variable,your solution requires duplicating lots of code. I'll think about > it... Step has 21 different types of objects and already 4 different "create" messages for them. The german language is really easy compared to some other languages (plural, syntax, grammar). To have proper translations in all language a lot of translation teams will have to deal with http://techbase.kde.org/Localization/Concepts/Transcript. What is a more simple solution for developers and translators together, + 17 additional "create" messages or a lot of teams dealing with transscript? I'd say + 17 messages. But please talk with Chusslove on #kde-i18n or by mail Chusslove Illich <caslav.ilic@gmx.net>, he is the guy who invented transscript and knows much more about translation problems especially in slavian laguages than me. > Object name (like disk1) can't be translated since it is defined by the > user. Hmm, I guess "disk1" is composed by the (translated) object name + consecutive numbering? So it should be possible to have Scheibe1 (disk1), Feder2 (spring2) etc in german? > However when examples and tutorials will be translatable it won't be > a big problem. > Numbers are not translated because they are shown in scientific format > (i.e. 1234567 => 1.235e+06). KLocale is not able to localize number in > this format and I think that the format itself is international, isn't it ? No, in german the decimal seperator is always the ',' (comma), the number format (fixed decimals 123,45 or scientific format 1,2345E+02) does not matter. I'am aware that the comma can't be used so far, it is already used to separate two values like coordinates eg (1.2, 3.4). The default decimal symbols for all kde languages are defined in kdebase/runtime/l10n/<language>/entry.desktop. grepping for "." (dot), "," (comma) and ";" (semicolon) shows only usage of dot + comma as decimal separator, so perhaps the semicolon could be used as value separator, thus making it possible to use the comma as decimal separator? > Unit names are not translated because these names should be parsable by > libqalculate. libqalculate has a very limited support for translating unit > names, and actual translations are available only for a few languages. Ah, I did not know that, I just wondered why a translated string is not visible. But why are the unit names offered for translation, if the translation is not used and displayed at runtime? What about separating the view with translated unit names from the internal use in libqalculate with the untranslated unit names?
> Step has 21 different types of objects and already 4 different "create" > messages for them. Ok, I can artificially duplicate that messages for each type of object. But Step also has messages like i18n("Move %1", _item->name()) where name is entered by the user (or composed by default like particle1). And even i18n("Change %1.%2", _item->name(), _property->nameTr()) where name is entered by user and property can have lots of values... > Hmm, I guess "disk1" is composed by the (translated) object name + > consecutive numbering? So it should be possible to have Scheibe1 (disk1), > Feder2 (spring2) etc in german? Got the idea, will fix. > The default decimal symbols for all kde languages are defined in > kdebase/runtime/l10n/<language>/entry.desktop. grepping for "." (dot), "," > (comma) and ";" (semicolon) shows only usage of dot + comma as decimal > separator, so perhaps the semicolon could be used as value separator, thus > making it possible to use the comma as decimal separator? Here we also depend on libqalculate: it parses each expression edited by the user to check if it contains something to calculate. I'll check how it deals with decimal separators. > But why are the unit names offered for translation, if the translation is not > used and displayed at runtime? Good question. I've thought about showing translated version when viewing and switching to raw version when editing, but then decided that is would be very inconsistent. > What about separating the view with translated unit names from the internal > use in libqalculate with the untranslated unit names? Internal representation of units in Step is very simple - each property can hold value in only one fixed units and that units are stored as constant text string. That string can easily be translated, but when editing the user still have to enter untranslated names for libqalculate to parse it.
(In reply to comment #4) > > Ok, I can artificially duplicate that messages for each type of object. But > Step also has messages like i18n("Move %1", _item->name()) where name is > entered by the user (or composed by default like particle1). And even > i18n("Change %1.%2", _item->name(), _property->nameTr()) where name is entered > by user and property can have lots of values... > I see your point here, in german I have no problem with "Move %1", _item->name() etc, but other languages may have it. I found a similar problem in kgeography in kde3, quoting from kgeography.po: msgid "" "_: There are two ways of dealing with the translation of \"%1 is the capital " "of...\". The first option simply replaces %1 with the translated name of the " "relevant city. If the grammar of your language allows this, choose this option " "by setting the translation of this message to 1, and leave untranslated the " "translations of \"%1 is the capital of...\" that have the placename embedded " "(or translate them as - if you wish to show the file as fully translated. The " "second option is to translate all messages in full - this is likely to be " "required in the case of highly-inflected languages like Russian. To choose this " "option, set the translation of this message to 0, and translate all the " "messages.\n" "0" msgstr "1"
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.