Robin
A 2190 strings, 8716 words desktop file isn’t possible to translate because of the volume.
It will never be finished in time and make translators quit.
Hi Henry
Firstly this is not a single .desktop file, but this is actually 517 individual .desktop files. I don’t think it would have been a good idea to flood transifex with 517 individual resources of merely 4 entries each (some few files have 5 or more). Moreover, when uploading .desktop files individually, they have no key-value pairing, each update means to empty the translations in them completely, while in the strings resource file type the key-value structure until now made absolutely sure none of the existing entries were cleared on update, (which obviously no longer is true at transifex. I’ll have to investigate what, why and when they have changed this behaviour.)
Secondly, if you know the English language on an advanced level, you can complete it in relatively short time for your native language. It took me three evenings to have it fully translated to German. But I admit, in many entries I had simply to accept what the TM had entered already, or to select the latest already existing translation from the “translation history” list always displayed on the right, right next to the entry field. Therein are displayed all formerly existing translations for the very entry in fulltext, and even reviewed ones show up, so you can decide within a second and then only proofread and click your OK. I mean, when reading a book in English language, you read more words in one go than just 8716 (which is not more than a chapter of 29 to 35 pages average), and if you are fit in your native language and know the “blind” 10 finger writing system (“touch system” in English language?), you key that stuff in mostly as fast you speak.
So no, I don’t believe translators will resign in the face of this challenge. Because merely half of the entries are actually new now and need a translation from scratch, the rest has been deleted by transifex unexpectedly and unwanted (which I stated that it has never happened before for this file type, as long the keys were consistent, which was made absolutely sure and triple checked before uploading the new version, so this removal of ~400 to 600 already translated strings should not have occurred.) The amount of new added strings doesn’t exceed the volume the first edition also had, which had proven to be translatable.
And many of the new strings are 1:1 duplicates from already existing entries, which reduces the workload additionally, since you merely have to check in them whether the TM respected the context properly while filling them in automatically. The duplication of entries is intentional, since it allows to translate the same wording to another meaning [which is not possible in other file types like .po, which causes constant trouble when a specific wording in English language (or source language) is used in a header line, a button and in floating text in a resource, and in translation this can’t be done with a single expression like in English. Or the same expression is used in English to express different meanings in two or more places of the program or script, which would require multiple expressions in the target language for entries of identical source language wording, which is not possible in e.g. .po files: They merge this to a single entry, so it is actually untranslatable then: If you translate to one of the possible meanings, all the other occurrences show up blatantly wrong. Ask Marcelo for this if you want more details.]
Windows is like a submarine. Open a window and serious problems will start.