In the Date column, the date doesn't display correctly except in english language Reproducible: Always Steps to Reproduce: Run trojita in other language (tested with french and greek) Actual Results: Displays the format (d mmm hh:mm) Expected Results: Display the local date See screenshots
Created attachment 89205 [details] Greek localisation
Created attachment 89206 [details] French localisation
"jourjourjour", "ώραώρα" ;-) Either the (KDE, using the KDE toolchain?) translators don't get the //: please do not translate the format specifier (you can change their order //: or the separator to follow the local conventions) message or fail to understand it. @Lasse, can you say what's failing here? Should we add an example for good and bad translation?
Yes, clearly those translations don't follow the format specification at http://qt-project.org/doc/qt-5/qdatetime.html#toString and that's wrong. Maybe it would be good to give that link to translators. I looked at http://l10n.kde.org/dictionary/compare-translations.php?package=extragear-pim&filename=trojita_common.po&compare=d+MMM+hh%3Amm and from there Danish and Dutch translations seem to be wrong as well. By the way both French and Greek translations of those format strings are currently fuzzy in /trunk/l10n-kde4. I don't know why translators sometimes translate these wrong even there is context information like what Thomas quoted. I saw that recently myself when proofreading someone else's translations. One reason for old translations could be that they were done before that context information was added. Adding a comment like //: doesn't make existing translations fuzzy.
Ok, I'm re-assigning this to i18n then.
Also it would be good to mention the reason why localizers should not translate the placeholders in the way they should be translated if the string was a placeholder text in a text input box and if that string was meant to help users know what format they are expected to input. Without a reason, some localizers might assume that a developer had no clue what things should and should not be translated and thus disregard the instruction. For example there have been developers who have thought that punctuation should never be changed in translation because they didn't know about languages where different punctuation is needed. Maybe that's not what happened, but still.
Sth. like this? //: this string is a direct code parameter, the used chars are IMPORTANT palceholders for the actual date //: good: "d MMM hh:mm" -> "MMM d hh/mm" //: acceptable: "d MMM hh:mm" -> "MMM, d hh:mm" (notice that the injected comma lenghtens the final string) //: BAD: "d MMM hh:mm" -> "t MMM ss:mm" (do NOT alter the chars to abbridge your local language!)
I looked at the comments/context_clarifiers in question, and they seem clear to me. I'm all for making them clearer, but I don't know how to do that, and therefore cannot do it myself. Patches are very welcome, it's evident that this has confused quite a few translators already. Perhaps marking the whole comment as a context would be the way to go?
I can hopefully make a patch sometime this week.
SVN commit 1405425 by glentadakis: Update Greek translation Remove datetime keys localisation M +334 -359 trojita_common.po WebSVN link: http://websvn.kde.org/?view=rev&revision=1405425
When the translation was commited, no such a comment existed: Revision 1346116 http://websvn.kde.org/trunk/l10n-kde4/el/messages/extragear-pim/trojita_common.po?revision=1346116&view=markup&sortby=author Then, as per revision 1379044: http://websvn.kde.org/trunk/l10n-kde4/el/messages/extragear-pim/trojita_common.po?r1=1378900&r2=1379044&sortby=author lines 3145,3323,3329,3336 were added, mentioning that : #. please do not translate the format specifier (you can change their order or the separator to follow the local conventions) without changing the relative msg to fuzzy.
Sorry that it has taken me so long to return to this. Yes, I think the current comments for translators are sufficient. How do we want to solve the issue of current broken translations for these messages? The following messages have some invalid translations according to http://l10n.kde.org/dictionary/compare-translations.php: MMMM yyyy hh:mm ddd hh:mm d MMM hh:mm Should someone just send a message to translators to kde-i18n-doc@kde.org (I can do it) and ask them to check those strings? And/or should we switch those comments into context (msgctxt) that makes existing translations fuzzy?
Hi Lasse, I have no idea how KDE's l10n teams work. I trust your judgement -- do whatever seems to be the good thing here.
(In reply to Lasse Liehu from comment #4) > I looked at > http://l10n.kde.org/dictionary/compare-translations.php?package=extragear- > pim&filename=trojita_common.po&compare=d+MMM+hh%3Amm and from there Danish > and Dutch translations seem to be wrong as well. A fix for the Dutch translations has been committed to trunk: http://websvn.kde.org/trunk/l10n-kde4/nl/messages/extragear-pim/trojita_common.po?r1=1417505&r2=1417504&pathrev=1417505
Git commit d320d072b50ebd0eebfc853e898f3173f2420da5 by Lasse Liehu. Committed on 09/04/2015 at 22:56. Pushed by gerrit into branch 'master'. Use disambiguation for messages containing date format specifiers This ensures that all currently invalid translations will be marked as fuzzy. This means that translators have to look what has changed and correct the translations before they show in the UI again. Change-Id: If9096578ec8bcf3a6074559f78cf1ac65c7a9607 M +4 -3 src/Imap/Model/MailboxTree.cpp M +9 -9 src/UiUtils/Formatting.cpp http://commits.kde.org/trojita/d320d072b50ebd0eebfc853e898f3173f2420da5
As far as I know, Lasse fixed this.