[VOTE INSIDE] The docs translation "problem"

[Shinjo Park]

D

For documents, in my opinion, the 75% should be based on the word count 
(excluding credits and licensing terms as they are boilerplate string), not 
the number of msgstr's as UI translations. From my previous experience, the 
source string for documentation has a bigger length variation than apps - e.g. 
title of the chapter is much shorter than the body text itself. If the 75% of 
source string has been reached by translating only very short strings, then it 
makes little sense as still a huge part of documentation is untranslated.

I've also seen some projects using the solution B, but I don't think this is 
optimal solution since:
* Changing back the app's language to English to see the English documentation 
requires a restart of KHelpCenter
* The effort to add a message that "newer version is not yet fully translated" 
systematically on any incomplete translations may be not worth than using the 
solution D

Shinjo

2024년 11월 15일 금요일 오후 5시 1분 23초 CET에 Albert Astals Cid 님이 쓴 글:
> Right now docs need to be generated manually by translators/team
> coordinators and commited to the docs/ folder.
> 
> This is something we don't communicate a lot and I'm sure some teams don't
> do that, not your fault.
> 
> Also it's relatively "easy" to commit broken docs that will break the
> application compilation (again not your fault again, the tooling is a bit
> fragile).
> 
> One of the things we were discussing with Luigi is to automate the docs
> compilation process.
> 
> Everyone likes automation, so that's a good thing, BUT there is a "problem",
> which is why we offloaded the compilation to humans in the first place.
> 
> The problem is that our current system, a particular documentation needs to
> be translated to 100% to be properly converted into an usable doc.
> 
> The easy solution is to remove a doc once it stops compiling, but that
> doesn't seem very optimal/fair because a single sentence would cause the
> doc to be removed and my understanding is that it's better to have a doc
> somewhat old doc translated than one with 0% translated.
> 
> The other easy solution is never to remove a doc even if it fails to
> compile, this can cause that the documentation gets SUPER OLD and then
> maybe it's not better to have a SUPER OLD translated documentation compared
> to a non translated documentation.
> 
> The middle ground (which is what we do with GUI messages) is to always
> generate the docs and if a particular string is missing use the English
> version of the string, this way we always have the newest documentation, as
> much translated as possible.
> 
> The middle ground of the middle group is fill missing translations with
> English but only if the translated percentage is bigger than say 75%
> 
> I think collectively want to move towards an automated system so we should
> adopt one of the 4 solutions described above (or if you have another
> magically perfect solution we have not thought about please say so).
> 
> PLEASE VOTE:
> 
> Which automatic solution do you prefer?
> 
> A) Remove translated documentation once they are not 100% translated
> 
> B) Keep previously 100% translated documentation once current version is not
> 100% translated
> 
> C) Use English text for non translated strings when generating translated
> documentation
> 
> D) Use English text for non translated strings when generating translated
> documentation but only if translated strings are > 75%, otherwise remove the
> translated documentation and use the English one.
> 
> I think I would vote for C, but I'm not really a translator nowadays so I'm
> not sure my vote counts.
> 
> Cheers,
>   Albert