Akademy meeting notes
Karl Ove Hufthammer
karl at huftis.org
Sun Sep 20 16:10:29 BST 2020
Albert Astals Cid skreiv 13.09.2020 12:26:
> * Web translation solution
> Unfortunately none of the strong proponents for it attended the meeting
> - The direct svn/git solution will stay to make sure our current users keep happy
Does that mean staying with SVN, or is a move to still Git possible?
While I think SVN is easier to learn and use than Git, people nowadays
are learning Git, not SVN. So I think that in the long run, it will be
better to move to Git (with one repository per language).
Note that all the complexity (and mental models) needed to really
*understand* both SVN and Git can be simplified away for the
translators. For example, for SVN, after the initial checkout, you
really only need to learn two really simple commands:
svn commit -m 'Commit message'
The thing complicating things for *new* translators, is (besides the
lack of a user-friendly ‘Getting started’ tutorial) is that they *don’t*
have commit access. So for new translators, the technical translation
process is actually much more complicated than for normal translators.
They have to prepare patches, send e-mail attachments, etc. With Git, I
guess ‘git format-patch’ can be helpful here? (I have never used it.) Or
merge requests on invent.kde.org? (They are *in theory* complicated, but
with a step-by-step tutorial tailored to the translators’ needs, they
need not be.)
> * l10n.kde.org
> We're hoping to eventually simply kill it. It uses old PHP (the code is relatively bad). Replace it with Damned Lies from gnome (which provides some other interesting functionality like file assignments)
Damned Lies looks like a good replace. But one thing I would miss, is
the ‘Compare Translations’ feature at
https://l10n.kde.org/dictionary/compare-translations.php. I don’t (need
to) use it very often, but when I do, it’s very useful.
> * Use of our infrastucture
> We need to try to make teams use our infrastructure for things as mailing lists, team guidelines, etc. Because we are sure our infrastructure will be maintained "forever", and sometimes external ones are not so stable/maintained
I guess that’s OK for larger ‘KDE translation teams’, but for some
languages, what’s defining the ‘team’ is not the project (KDE software),
but the language. For example, for the two Norwegian languages, we have
a mailing list for discussing Norwegian translations, terminology etc.
for free software in general, i.e., *across* several translation
projects. And most of the members are not (active) translators at all;
they’re users – users interested in having a variety of free software in
their native language. IMO, this is much more useful than having siloed
mailing lists that KDE-specific, GNOME-specific, freedesktop-specific, etc.
> * Move data files over to application repositories
> We agreed that moving the data files over application repositories makes sense. This way on the svn we only have things whose translations are done via po files. Will need to contact developers to convince them it's a good thing too :)
> Unrelated to that we need to improve discoverability of which applications have translatable data files.
KTuberling has solved this in a nice way. There’s a special string in
ktuberling.po(t) with the following msgid (and a msgctx of ‘NOTE TO THE
The translators have the opportunity to translate the\n
sounds spoken in the game.\n
See the technical reference section in ktuberling's\n
documentation for more information on how to do that.\n
(translate this message as "DONE" when you have translated\n
the sounds; otherwise leave it untranslated as a reminder)
Karl Ove Hufthammer
More information about the kde-i18n-doc