| Summary: | I18N done wrong on Umbrello worktoolbar | ||
|---|---|---|---|
| Product: | [Applications] umbrello | Reporter: | Peeter Russak <pezz> |
| Component: | general | Assignee: | Umbrello Development Group <umbrello-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | worktoolbar i18n fixes | ||
Created attachment 3871 [details]
worktoolbar i18n fixes
Patch does two things
1) changes Umbrello's name from Umbrello UML Modeller to Umbrello in
Tools->Configure Umbrello and Help->About Umbrello. It was discussed in list
and is wise thing to do to make UI consistent with outher apps and translators
happy.
2) Fixes wrong usage of i18n() in worktoolbar
Thanks, it's on obvious mistake once it's been pointed out. I've applied the patch. Name section not applied because we arn't changing the name (but feel free to translate it in the way which makes the most sence). Damn you, englishmen. Next app I create I'll name 'J All I want to say is that it's OK if description is in about dialog, but having name that contains multiple words in name is evil, because not all languages are using prefixes and suffixes, but they changes words' endings and their word ordering is different. In this case: if I translate string 'Umbrello UML Modeller' (that appears in appname and in about dialog) into 'Umbrello - UMLi modelleerimise vahend' then it's OK for about dialog, but in menu it appears 'Umbrello - UMLi modelleerimise vahend seadistamine' when there should be 'UMLi modelleerimise vahendi Umbrello seadistamine'. Sometimes things are even more complicated. Get it? I really hope so. If not, then take a beer read this: http://www.hiiumaa.ee/douglas/keel.htm It's not coincidence that 99.99% of applications have one-word names. There are other programs with descriptive names: KDE Advanced Text Editor, K Desktop Environment etc. Our difference is that we (well I do at least) like to use the full name so people immediatly know what it is. But if that doesn't translate well translate it as just "Umbrello". And I'm a Scotsman not an Englishman! Think yourself lucky we didn't name it something in Scots. :) Oh, sorry about calling you Englishman then:)
It's not about someone wanting to cut your glory, it's just about sane programming. String that is merged into multiple places in menus should be short to fit in better. People get immediate understanding from menu where it's name is already Umbrello (UML Modeller). While using Kate you don't want to know every time that your text editor is ADVANCED, you already know it from menu.
If you like Kate then look at it's source:
KAboutData aboutData ("kate", I18N_NOOP("Kate"), "2.2",
I18N_NOOP( "Kate - Advanced Text Editor" ), KAboutData::License_LGPL_V2,
I18N_NOOP( "(c) 2000-2003 The Kate Authors" ), 0, "http://kate.kde.org");
vs
static const char *description =
I18N_NOOP("Umbrello UML Modeller");
KAboutData aboutData( "umbrello", I18N_NOOP("Umbrello UML Modeller"),
UMBRELLO_VERSION, description, KAboutData::License_GPL,
I18N_NOOP("(c) 2001 Paul Hensgen, (c) 2002-2003 Umbrello UML
Second parameter is the one that is used in menus. See the difference? Look at any other application if you still don't believe.
In PO-file appearance of same strings are translated in on string message so when I translate this string as 'Umbrello' for my reasons we loose description also from about dialog where it fits well.
|
Version: 1.2-beta (using KDE 3.1.94 (CVS >= 20031206), compiled sources) Compiler: gcc version 3.3.1 (SuSE Linux) OS: Linux (i686) release 2.6.0 String extraction AI is not that smart to detect strings that are given as string input to function, so this definition works, but is I18N-wise wrong and most of worktoolbar button texts are not extracted for translation: void WorkToolBar::insertHotBtn(ToolBar_Buttons tbb, const char *label) { insertButton(m_Pixmaps[tbb], tbb, true, i18n(label)); I'll attach patch that corrects the problem.