After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 630039 - [i18n] Inappropriate translation when concatenated UI string contains variable
[i18n] Inappropriate translation when concatenated UI string contains variable
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: general
git master
Other All
: Normal normal
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-09-19 05:47 UTC by Zhou Ting
Modified: 2010-10-18 11:22 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
snapshot: "Music Folder" in russian language (84.95 KB, image/pjpeg)
2010-09-19 05:53 UTC, Zhou Ting 		Details

Description Zhou Ting 2010-09-19 05:47:40 UTC 
In LibrarySource.cs, there is string:    
Catalog.GetString ("{0} Folder")
{0} can be "Music", "Videos", "Podcasts" 

In ru.po:
msgid "{0} Folder"
msgstr "Папка {0}"

msgid "Music"
msgstr "Музыка"

msgid "Videos"
msgstr "Видео"

msgid "Podcasts"
msgstr "Подкасты"


So the UI will display 
"Music Folder" as "Папка Музыка", but is should be  "Папка с музыкой"


I think the we'd better avoid variables in UI string, because in some languages, words can not be directly concatenated to form a string.
Comment 1 Zhou Ting 2010-09-19 05:53:09 UTC 
Created attachment 170580 [details]
snapshot: "Music Folder" in russian language
Comment 2 Gabriel Burt 2010-09-22 17:40:53 UTC 
Is the problem is that for Videos or Podcasts or some other library that "Папка с" isn't what "{0} Folder" would be translated to?
Comment 3 Alexander Kojevnikov 2010-09-23 03:36:01 UTC 
The problem is that the translation for word "Music" cannot be used in "{0} Folder", the noun's suffix changes depending on the context.

This can be fixed by implementing an abstract property in all derived classes, but I guess we should wait with this until after 1.8 because of the string freeze.
Comment 4 Gabriel Burt 2010-09-27 22:16:32 UTC 
Ok, yeah will have to be post-1.8.0.  Instead of an abstract property, we could just use the property bag (src.Properties) like we do for overriding action labels etc.
Comment 5 Alexander Kojevnikov 2010-10-18 11:22:55 UTC 
(In reply to comment #4)
> Instead of an abstract property, we could
> just use the property bag (src.Properties) like we do for overriding action
> labels etc.

This approach wouldn't work because the string is needed in the base ctor which runs before derived classes have a possibility to add the string to the property bag.

I implemented it using an abstract property, closing as FIXED.