Version: (using KDE KDE 3.5.3) Installed from: Mandriva RPMs OS: Linux one of the filters should be translated as "Do:" instead of "Komu:" screenshot: ftp://tropikhajma.vserver.cz/bugs/konq-image-filter.png
I couldn't find the corresponding .po file. Please could you specify which konqeror module implements this filter? How do you start this filter. Isn't it Mandriva specific tool?
Pohled (View) -> Režim zobrazení (View mode) -> Prohlížeč obrázků (Image viewer) then in the left pane check "More" i dont think it is mdv specific
messages/extragear-graphics/kst.po ?
nenasel jsem to. Prosimte poslal bys mi vypis bezicich procesu, abych zkusil identifikovat podezrele?
Dne pondělí 07 srpen 2006 14:50 flidr@kky.zcu.cz napsal(a): [bugs.kde.org quoted mail] [hajma@localhost ~]$ ps aux > aux1 Created an attachment (id=17363) aux1 Created an attachment (id=17364) konqtransbug2.png Created an attachment (id=17365) konqtransbug1.jpg
I think it is in gwenview (http://websvn.kde.org/trunk/l10n/cs/messages/extragear-graphics/gwenview.po?rev=574627&view=log) #. i18n: file ./gvcore/filterbar.ui line 164 #: rc.cpp:406 #, no-c-format msgid "To:" msgstr "" Absence of translation makes it use some default translation from somewhere else, where it is used in different meaning, I guess
Thanks, I updated the translation. You can try to download the http://websvn.kde.org/trunk/l10n/cs/messages/extragear-graphics/gwenview.po file and the use msgfmt command to produce gwenview.mo. Them place this file to /usr/share/locale/cs/LC_MESSAGES or $KDEDIR/share/locale/cs/LC_MESSAGES directory.
Thanks, I did as you told me, but only gwenview's interface changed. The embedded gwenview in konqueror (I believe it is this way because it is very very similar) did not, which is weird as I also performed a search for other messages from this embedded thing and the only match that appeared was gwenview.mo. I even restarted the computer. Perhaps this might help (cut to contain only pid 6162, which is the konqueror with the embedded filter): [root@localhost kdm]# lsof | grep \\.mo$ konqueror 6162 hajma mem REG 22,1 140069 1717286 /usr/share/locale/cs/LC_MESSAGES/kio.mo konqueror 6162 hajma mem REG 22,1 58721 1717020 /usr/share/locale/cs/LC_MESSAGES/konqueror.mo konqueror 6162 hajma mem REG 22,1 3905 1717228 /usr/share/locale/cs/LC_MESSAGES/kfile_jpeg.mo konqueror 6162 hajma mem REG 22,1 21363 1693916 /usr/share/locale/cs/LC_MESSAGES/gwenview.mo konqueror 6162 hajma mem REG 22,1 10802 1717141 /usr/share/locale/cs/LC_MESSAGES/kcmkurifilt.mo konqueror 6162 hajma mem REG 22,1 1111 1717559 /usr/share/locale/cs/LC_MESSAGES/searchbarplugin.mo konqueror 6162 hajma mem REG 22,1 5143 2314484 /usr/share/locale/cs/LC_MESSAGES/libkonq.mo konqueror 6162 hajma mem REG 22,1 171535 1717180 /usr/share/locale/cs/LC_MESSAGES/kdelibs.mo konqueror 6162 hajma mem REG 22,1 86276 1809577 /usr/share/locale/cs/LC_MESSAGES/libc.mo kio_file 6172 hajma mem REG 22,1 171535 1717180 /usr/share/locale/cs/LC_MESSAGES/kdelibs.mo kio_file 6172 hajma mem REG 22,1 86276 1809577 /usr/share/locale/cs/LC_MESSAGES/libc.mo
It seems to be not only Czech problem; I've same problem in Estonian ("Kellelt" and "Kellele", not "Alates" and "Kuni". And relevant entries are translated into Estonian, so the problem has to be in where translation is taken of... Something is really messed up, I think...
It probably takes the translation from kdelibs.po and not from the gwenview.po. As the above mentioned lines from gwenview.po indicate, the text in the bar should be definitely taken from this translation as it corresponds to filterbar.ui.
Sorry, but I do not understand why you have closed the bug. I see that it is not a translation problem, but rather core issue. So the correct approach would be to reassign the bug, not close.
Has it to be reassigned to Gwenview or Konqueror?
Let's try to reassign to Gwenview - after all it's their KPart which is responsible for that...
Seems still be valid...
Translations are i18n/doc group issues, not gwenview. Of course if you mean that the problem still exists on your distro, well you should consider that a) a new version of gwenview(-i18n) has not been released since 1.4.1. that means you should try it from svn - expecially for translations. b) if you open a bug for your distro maybe gwenview maintainer can (if the po file has been released, remember distro maintainers can't know any languages) provide a patch from svn for it Angelo
The problem that exists same in different translations can't be translation problem as such, there has to be smth wrong with application itself (maybe it *was* and now isn't but the BR is more than year old...)
Alle sabato 4 agosto 2007, Marek Laane ha scritto: [bugs.kde.org quoted mail] That does mean that some strings were not translated at the time gwenview 1.4.1 has been released (e.g. 2006.11.26) and so it could be a translation problem, your mother language is different than mine, so i could (I'm not a traslator though) translate for Italian, but sure i don't for any other ones. So do other translators. > there has to be smth wrong with application itself (maybe it *was* and now isn't but the BR is more than year old...) IIUC this bug some users haven't found the right translation for their language, that can be for two reasons, a) developers missed i18n management (gwenview issue) b) some translators haven't translated it yet or the meaning is not clear for their language. a) I could say Aurelien usually manages i18n, it's hard to find he doesn't. In such a case you should find the English term anyway. Following the thread i can see that the affected file should be gvcore/filterbar.ui that is a qt-designer file so strings are implicitally managed So IMO it's b) and the only way to solve is checking if the strings are correttly translated in svn by now, asking for a patch to distros (open a bug against mandriva if you are a mandriva user, i will be happy to provide a patch, if exists since i cannot speak -and write- your language :) ) Well another way could be having a new gwenview version out :D
IIUC the problem is not that strings were/are untranslated but that wrong translations were/are used (From/To as in email - that is wrong). That's something I just couldn't understand... I've just now no chance to check out were e.g. Estonian translation (in gwenview.po) wrong in the past (KDE websvn seems to be down) but I'm quite sure it has been right quite a long time (And yes I've Mandriva user but i wouldn't open the bug there before i'm sure it really has something to do with distro/packaging)
svn cat svn://anonsvn.kde.org/home/kde/trunk/l10n-kde3/it/messages/extragear-graphics/gwenview.po > gwenview.po substitute "it" with your code. if exits you'll have gwenview.po local on your directory. > (And yes I've Mandriva user but i wouldn't open the bug there before i'm sure it really has something to do with distro/packaging) It is *not* a distro packaging problem, but you won't have any backport on your distro if you don't ask for it to distro maintainer (ok it's me mandriva's, but that's not the point we're talkinga about the way to do). And without an open ticket (bug or call as you like) maintainer cannot backport/update anything.
Yeah, I know, I meant I haven't just now any chance to check history of translation, i.e what were changed when. In my local copy (I'm KDE translator, too) there is right translation and I'm quite sure it has been so long time, I just can't prove it now. I was just not very sure it is really translation problem - you see, there has been similar problems, especially with such "short words" what may have different meanings in different languages (.e.g. 'From' may be translated differently as in email field or as in range denominator - and if developer e.g. uses not direct i18n calls but macros defined in kdelibs, it may lead wrong translation)
Anyway, that seems to be not "distro's problem" anyway - I noticed you have updated gwenview-i18n on Mandriva, installed it but the error is still there (see attached image - strings are same as indicated in comment #9 which are false)
Created attachment 21354 [details] Still erroneous strings in Gwenview KPart
> ------- Additional Comments From bald starman ee 2007-08-09 16:16 ------- > Anyway, that seems to be not "distro's problem" anyway - I noticed you have updated gwenview-i18n on Mandriva, It's not a distro problem. agree in that. I rebuilt (not updated) gwenview-i18n for cooker, because it has not been done before, i forgot it as soon as new cooker (next 2008.0) started. > installed it but the error is still there (see attached image - strings are same as indicated in comment #9 which are false) Since i *rebuilt* it, it's always the same package not an update. Which is the right czech localization file (sorry for my ignoranze, but i don't know it)? I could try to download it and see if there are differences and, in that case fixing it. In such a case, i need a bug on mandriva to update it for 2007.1, otherwise i can do it only for cooker, that's why i need a distro ticket.
Ah, I see... I myself use cooker anyway, but updating translations probably won't break anything either in backports... Czech localization file is probably http://websvn.kde.org/trunk/l10n-kde3/cs/messages/extragear-graphics/gwenview.po (and Estonian is same, only cs->et: I just checked, both have correct translations, Od/Do and Alates/Kuni, respectively)
Created attachment 21357 [details] cs gwenview.mo Could you please test if this one it's better the one released into tarball?
comment #24: that means this bug is fixed. about (ot) mandriva, i can backport, but i cannot update. Official updates must follow a way to. I'll see what i can do.
Hmm, are you sure it s fixed? As I've no czech locale, I made correspondent mo for Estonian but still see same error...
sorry you said "I just checked, both have correct translations, Od/Do and Alates/Kuni, respectively) " so i understood is ok, i was porting them to mandriva. but if they are not... re-open it...
I meant translation files have right translations but alas, it doesn't always guarantee right output, too (maybe I did smth wrong but replacing old mo-file with new, generated from the po indicated in comment #24 and after that opening the view in Konqueror didn't fix the error)
could you test http://www.linux.it/~anaselli/TEST/gwenview-i18n-1.4.1-3mdv2008.0.i586.rpm please?
Essentially same.The problem has to be in a way Gwenview embedded in Konqueror uses translations - in Gwenview itself translation is right but embedded in Konqueror it isn't. See next screenshot: on the right is standalone Gwenview with right translations, on the left Gwenview embedded in Konqueror with wrong translations.
Created attachment 21358 [details] Example of right and wrong translation (on the right and on the left, respectively)
Ok now a test that definitively shows, at least in my opinion, that it's not a gwenview issue, neither for translations. I removed gwenview-i18n package so that gwenview worked in English only. The gwenview application isn't (that's right) translated, the kpart one, using the show image (or the way is in English) icon on konqueror shows some words inside gwenview are translated and some aren't. Here for instance "From:" and "To:" are, so that means they are not taken from gwenview.mo but somewhere else.
That was because I was not very sure to which product to assign (see comment #12) but isn't Gwenview Kpart, i.e embedding into Konqueror also Gwenview's developers work? Or what or how handles directives to use translations when embedded?
> That was because I was not very sure to which product to assign (see comment #12) but isn't Gwenview Kpart, > i.e embedding into Konqueror also Gwenview's developers work? Or what or how handles directives to use translations when embedded? I'm afraid the last one. I suspect that is the priority, is the string in konqueror translations? if yes take that one otherwise... But I maybe wrong.
AFAIK these strings appear in kdelibs.po (but from kdeui/kbugreport.cpp what seems very unlikely) and of course in kmail.po, also in knode.po, kontact.po, kalarm.po, korganizer.po (in Estonian wrong strings are exactly same as email's fields From and To).
Well I don't really know, I hope some gurus can help here. I moved my konqueror.mo from /usr/share/locale/it/LC_MESSAGES to a backup dir and From:, To: remains in English. As soon as it is back those words are translated again.
Hmm, konqueror.po hasn't the strings, so it has to obtain them from somewhere else... (I just add David Faure to CC, he usually knows very much about mysterious ways KDE behaves... :-) )
> Hmm, konqueror.po hasn't the strings, so it has to obtain them from somewhere else... Try it yourself and let me know if it works in the same way i said :)
I tried to remove konqueror.mo (without removing any other konqueror-related mo-files and also not removing gwenview.mo): all the view was in English, also our strings... Then I tried to remove gwenview.mo (without removing anything konqueror-related) and our strings were translated, though not all: translated were From and To, also Other (checkbox) and tooltip Details (in upper row first on left where you can toggle sidebar's view)
Quickly reading the posts, and giving my idea about the issue: there are the strings "From:" and "To:" globally defined in the kdelibs.mo catalog, and this catalog (along with kio.mo and all the catalogs the applications wants) are loaded, and messages looked into them. I see gwenview has "From:" and "To:" in its messages, then my idea is to mark these messages with a context. The context would prevent the kdelibs' "From:" and gwenview's "From:" to be recognized as the same message. To translate to code, if you have i18n("From:") in gwenview, turn it into eg: i18n("gwenview", "From:") and see whether this works.
Pino, it's an ui file generated by QT-designer, more precisely a text label. I wonder if i can use the comment filed in a way like you said, is there any standard way to? Does that mean translations are broken anyway if i release a new ui file with a comment into text label? TIA, Angelo
Hm, I don't remember how a context in the .ui file is handled by the KDE 3 locale system. One solution that could be done for sure is removing these strings from the .ui, and set them dynamically in the implementation of the widget, thus adding the proper context. It's a bit raw, but it should do the trick.
> One solution that could be done for sure is removing these strings from the .ui, and set them dynamically in the implementation of the widget, > thus adding the proper context. It's a bit raw, but it should do the trick. hmm, i'll ask for it to Aurelien as soon as he's back, but that sounds like a joke to me, because all the strings used into ui files are under that problem, so the solution should be not to use ui files more than changing all the strings inside the code... e.g. both not applicable i believe.
Is Aurelien back and ready to give his opinion? (If I'm not mistaken I've seen some of his commits, though probably not related with this BR...)
I finally took the time to have a look at the problem and what happens is kdelibs.mo is "shadowing" gwenview.mo. If I rename kdelibs.mo to something else the labels from the filter bar are correctly translated. I can see two possible solutions: First is to set a context to the translations, as Pino suggested in #41 and #43. I would suggest adding code like this in gvcore/fileviewcontroller.cpp in the Private::initFilterBar() method: QString fromText = i18n("gwenview", "From:"); QString toText = i18n("gwenview", "To:"); mFilterBar->textLabel1_2->setText(fromText); mFilterBar->textLabel2->setText(toText); A nicer fix would of course rename the labels in the .ui file to avoid code like "mFilterBar->textLabel1_2" which is just ugly. This fix would require updating translations, since the "From:" and "To:" strings would then be seen as new strings. Another solution is to modify gvdirpart/gvdirpart.cpp. In GVDirPart::GVDirPart(), find this line: KGlobal::locale()->insertCatalogue( "gwenview" ); And add this one after: KGlobal::locale()->setActiveCatalogue("gwenview"); This solution avoids the need to update translations. Only thing is I am not sure it does not cause Gwenview translations to appear in Konqueror where it should have used kdelibs translations.
Well, if the second option is doable, it'll be of course preferable, but even first option would be better than recent situation... (But it still doesn't answer the question why kdelibs strings are preferred to gwenview strings? It should be otherwise...)
SVN commit 712819 by gateau: Make Gwenview translations the active ones in KParts. BUG: 130511. M +3 -1 NEWS M +2 -1 gvdirpart/gvdirpart.cpp M +2 -1 gvimagepart/gvimagepart.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=712819