[VOTE INSIDE] The docs translation "problem"
Yaron Shahrabani
sh.yaron at gmail.com
Fri Nov 15 18:22:25 GMT 2024
D sounds reasonable although I haven't talked a single documentation string
in this project.
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.
Maybe I'm being too optimistic but it's a better use of my time and will
benefit other projects as well.
Thanks!
On Fri, 15 Nov 2024, 19:20 Shinjo Park, <kde at peremen.name> wrote:
> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20241115/29b17e79/attachment-0001.htm>
More information about the kde-i18n-doc
mailing list