Hello lists, Cross-posting to meego-dev, but further discussion probably belongs to meego-il10n only. Please come if you have anything to add.
I know this is late and probably won't do much before our string freeze,
but I've only noticed that yesterday and got confirmation today and at
this point it's enough that we discuss it, no actions required.
I'm not sure if it was discussed anywhere in the open, and if so - sorry
I missed that discussion. Either way, it was decided that translatable
strings should go to separate files, e.g. [1,2].
I strongly vote against this. The most important reason: it's impossible
to use plural forms with that approach. Because plural handling depends
on the third argument in the call to qsTr(), the output is dynamic. You
can't cache it as some static value. See [3] for a direct result. I had
to move qsTr() back to the original QML file it was extracted from, just
to get plural handling done.
More reasons against:
* it's difficult to read the code jumping back and forth between
two files to check if the translatable string corresponds
correctly to where it is. I can see many cases where that
approach will lead to problems when translatables are out of
date, because the developer can't immediately see the string
he's working around;
* the location tags for translations lose all meaning, translators
which would like to get some additional context have to grep
through the code to find where the string is actually used;
The reason for the decision made, as per the commit message, was not to
break string freeze when layout changes. I can't understand that? As
long as no strings' contents, comments (disambiguation), and/or possibly
extracomments, are changed, there's no break as the i18n tools will
handle everything even without updating the .ts / .qm file. The location
tags don't matter here at all.
I can see one advantage of using separate files, and that is common
translatables for multiple QML files, but it's a dirty workaround for
things that should get fixed in Qt [4,5,6,7]. Please also see my
previous post about translation contexts in QML [8] that can properly
solve this problem in the mean time.
[1]
https://meego.gitorious.org/meego-ux/meego-app-im/blobs/9251cb2fbd7d62436c95f131c484c8d6ea49dd75/constants.js
[2]
https://meego.gitorious.org/meego-ux/meego-app-im/commit/9251cb2fbd7d62436c95f131c484c8d6ea49dd75
[3]
https://meego.gitorious.org/meego-ux/meego-app-im/merge_requests/8#3061d36dda68904ccce12ffb7d1f1bf88710d9f4-3061d36dda68904ccce12ffb7d1f1bf88710d9f4@2
[4] http://bugreports.qt.nokia.com/browse/QTBUG-11793
[5] http://bugreports.qt.nokia.com/browse/QTBUG-11859
[6] http://bugreports.qt.nokia.com/browse/QTBUG-15503
[7] http://bugreports.qt.nokia.com/browse/QTBUG-15460
[8] http://lists.meego.com/pipermail/meego-il10n/2011-June/000519.html
Best regards,
--
Michał Sawicz <[email protected]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
