Akademy meeting notes

[Karl Ove Hufthammer]

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 update
   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 
TRANSLATORS’):

    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