> [: Luc Pionchon :] > However when a document is mostly translated, for example after a software > update with a few new strings and a few fuzzy, I feel that the string > count is more meaningful to get an idea of the work to do. The following works nice for fuzzy messages. Since the previous original text (#| msgid "...") is available, first make a word-level diff of current and previous original text. Then count how many words are the same for both. If that number is over a relative threshold of total word count for current text, say over 50%, add it to translated word count, and add the remainder to untranslated. If it is below the threshold, add the full word count to untranslated. This provides the most informative word count when e.g. one paragraph-long message got only two words changed, and another was so badly mauled that it must effectively be translated from scratch. (When this is done, the word count associated to fuzzy messages is always zero.) > The point is that a single word can be greatly more difficult to translate > that a sentence, especially in UI (in opposition to a document) where > space is limited for single word strings. Right, and a good measure of that is the average number of words per message. For a typical GUI program, with short labels and longer tooltips, this is about 5-6. For a typical piece of documentation it is 15-20[*]. For collections of items, 1-2. [*] Which, unfortunatelly, is on the trivial side, but that's how it is. If a piece of documentation has < 10 words/message, it should be deleted outright. "Use File->Open to open a file." I found the shortest sufficiently good quantification of effort, performed and remaining, to be the following three numbers: number of translated words, number of untranslated words (with fuzzy redistribution as above), average number of words per message. -- Chusslove Illich (Часлав Илић)
Attachment:
signature.asc
Description: This is a digitally signed message part.