написане Sat, 29 Jan 2011 10:16:15 +0200, Dimitris Glezos
On Fri, Jan 28, 2011 at 10:45 PM, Yuri Chornoivan
> Transifex 1.0 effectively breaks Ukrainian translations. Plural form in
> your system is wrong. [...]
> I cannot even guess from where these forms were taken?
Thanks for taking the time to help report this. The plural forms were
taken from here:
Very strange doc. If we use it, then Ukrainian for 1000032 will be "few"
and 7 will be "many". It is absolutely non-trivial task to know what is
"few" and what is "many". Some time ago, one of the Russian
(boobaloo) wrote me about this. As it can be easily seen the use of this
doc just remove the plural translations from Ukrainian Anaconda (though LP
and Virtaal, for example, just cut off the fourth form (see below)).
> The right form
> Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2
> n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n
> Plural-Forms: nplurals=4; plural=n==1 ? 3 : n%10==1 && n%100!=11 ? 0 :
> n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n
Should we reduce n to 3, or use the latter equation? Where is the
first used and where the last?
First (traditional) form is used in Qt (hardcoded), most (but not all)
GNOME translations (Ukrainian GNOME stagnates now), LP (hardcoded), Pootle
(hardcoded). Some CAT applications alos have this hardcoded (Virtaal). It
gives very awkward result in some cases (Shotwell is a prominent example).
The reason of the problems is the form for 1, 21, 31, 41... This form
fails in cases like as follows (Shotwell):
msgid "Export Photo/Video"
msgid_plural "Export Photos/Videos"
Any translation with 3 forms will be failure. More dramatic example
msgid "Unable to duplicate one photo due to a file error"
msgid_plural "Unable to duplicate %d photos due to file errors"
Any translation will be vague for the user. You might think it's just
usability issue, but developers like it (GNOME, KDE, etc.).
The new form is used in KDE, some TP and GNOME projects. It allows
correctly translate the given examples.
interface is sluggish not faster than today's
Can you please be specific? My experience is that most parts are way
faster. We have added tons of caching code and almost the whole
website should be MUCH faster. Especially the important parts of the
site, such as stats, the releases and the web editor. One of the parts
which we will improve in the upcoming release is file exports.
AFAIK, users of translate.fedoraproject.org
complained not about web
editor (though there were also complains about this). They complain about
export and import. Well, test stand:
Core2 Duo 4700, 4 GB RAM, NVidia GeForce 9600 GT, Mandriva 2010.2, KDE
4.4, Opera 11.01 (well, well, it's not reference Fedora workstation, but
you can test it by yourself):
txn: 10 s to export Anaconda Ukrainian translation
tfo: 7 s to export Anaconda Ukrainian translation
There is no parity in import (you cannot import Anaconda translation to
txn), but for me it takes the longer time to import Shotwell translation
(726 messages) to txn (~1 min + 1 failure with ~3 min waiting) than to
import anaconda translation to current tfo (~40 s).
Thanks for testing and providing constructive feedback.
Thanks for correcting this issues.