<p dir="ltr">D sounds reasonable although I haven't talked a single documentation string in this project. </p>
<p dir="ltr">I'm just waiting for LLMs to become more cost efficient, train a RAG on the UI strings and apply the style and terms to the docs translation.<br>
Maybe I'm being too optimistic but it's a better use of my time and will benefit other projects as well.</p>
<p dir="ltr">Thanks!</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 15 Nov 2024, 19:20 Shinjo Park, <<a href="mailto:kde@peremen.name">kde@peremen.name</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">D<br>
<br>
For documents, in my opinion, the 75% should be based on the word count <br>
(excluding credits and licensing terms as they are boilerplate string), not <br>
the number of msgstr's as UI translations. From my previous experience, the <br>
source string for documentation has a bigger length variation than apps - e.g. <br>
title of the chapter is much shorter than the body text itself. If the 75% of <br>
source string has been reached by translating only very short strings, then it <br>
makes little sense as still a huge part of documentation is untranslated.<br>
<br>
I've also seen some projects using the solution B, but I don't think this is <br>
optimal solution since:<br>
* Changing back the app's language to English to see the English documentation <br>
requires a restart of KHelpCenter<br>
* The effort to add a message that "newer version is not yet fully translated" <br>
systematically on any incomplete translations may be not worth than using the <br>
solution D<br>
<br>
Shinjo<br>
<br>
2024년 11월 15일 금요일 오후 5시 1분 23초 CET에 Albert Astals Cid 님이 쓴 글:<br>
> Right now docs need to be generated manually by translators/team<br>
> coordinators and commited to the docs/ folder.<br>
> <br>
> This is something we don't communicate a lot and I'm sure some teams don't<br>
> do that, not your fault.<br>
> <br>
> Also it's relatively "easy" to commit broken docs that will break the<br>
> application compilation (again not your fault again, the tooling is a bit<br>
> fragile).<br>
> <br>
> One of the things we were discussing with Luigi is to automate the docs<br>
> compilation process.<br>
> <br>
> Everyone likes automation, so that's a good thing, BUT there is a "problem",<br>
> which is why we offloaded the compilation to humans in the first place.<br>
> <br>
> The problem is that our current system, a particular documentation needs to<br>
> be translated to 100% to be properly converted into an usable doc.<br>
> <br>
> The easy solution is to remove a doc once it stops compiling, but that<br>
> doesn't seem very optimal/fair because a single sentence would cause the<br>
> doc to be removed and my understanding is that it's better to have a doc<br>
> somewhat old doc translated than one with 0% translated.<br>
> <br>
> The other easy solution is never to remove a doc even if it fails to<br>
> compile, this can cause that the documentation gets SUPER OLD and then<br>
> maybe it's not better to have a SUPER OLD translated documentation compared<br>
> to a non translated documentation.<br>
> <br>
> The middle ground (which is what we do with GUI messages) is to always<br>
> generate the docs and if a particular string is missing use the English<br>
> version of the string, this way we always have the newest documentation, as<br>
> much translated as possible.<br>
> <br>
> The middle ground of the middle group is fill missing translations with<br>
> English but only if the translated percentage is bigger than say 75%<br>
> <br>
> I think collectively want to move towards an automated system so we should<br>
> adopt one of the 4 solutions described above (or if you have another<br>
> magically perfect solution we have not thought about please say so).<br>
> <br>
> PLEASE VOTE:<br>
> <br>
> Which automatic solution do you prefer?<br>
> <br>
> A) Remove translated documentation once they are not 100% translated<br>
> <br>
> B) Keep previously 100% translated documentation once current version is not<br>
> 100% translated<br>
> <br>
> C) Use English text for non translated strings when generating translated<br>
> documentation<br>
> <br>
> D) Use English text for non translated strings when generating translated<br>
> documentation but only if translated strings are > 75%, otherwise remove the<br>
> translated documentation and use the English one.<br>
> <br>
> I think I would vote for C, but I'm not really a translator nowadays so I'm<br>
> not sure my vote counts.<br>
> <br>
> Cheers,<br>
>   Albert<br>
<br>
<br>
<br>
<br>
</blockquote></div>