<div dir="ltr">oh!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 21 Sep 2020 at 02:02, Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">El diumenge, 20 de setembre de 2020, a les 17:10:29 CEST, Karl Ove Hufthammer va escriure:<br>
> Albert Astals Cid skreiv 13.09.2020 12:26:<br>
> > * Web translation solution<br>
> ><br>
> > Unfortunately none of the strong proponents for it attended the meeting<br>
> ><br>
> > - The direct svn/git solution will stay to make sure our current users keep happy<br>
> <br>
> Does that mean staying with SVN, or is a move to still Git possible?<br>
> <br>
> While I think SVN is easier to learn and use than Git, people nowadays <br>
> are learning Git, not SVN. So I think that in the long run, it will be <br>
> better to move to Git (with one repository per language).<br>
> <br>
> Note that all the complexity (and mental models) needed to really <br>
> *understand* both SVN and Git can be simplified away for the <br>
> translators. For example, for SVN, after the initial checkout, you <br>
> really only need to learn two really simple commands:<br>
> <br>
>    svn update<br>
>    svn commit -m 'Commit message'<br>
> <br>
> The thing complicating things for *new* translators, is (besides the <br>
> lack of a user-friendly ‘Getting started’ tutorial) is that they *don’t* <br>
> have commit access. So for new translators, the technical translation <br>
> process is actually much more complicated than for normal translators. <br>
> They have to prepare patches, send e-mail attachments, etc. With Git, I <br>
> guess ‘git format-patch’ can be helpful here? (I have never used it.) Or <br>
> merge requests on <a href="http://invent.kde.org" rel="noreferrer" target="_blank">invent.kde.org</a>? (They are *in theory* complicated, but <br>
> with a step-by-step tutorial tailored to the translators’ needs, they <br>
> need not be.)<br>
> <br>
> <br>
> > * <a href="http://l10n.kde.org" rel="noreferrer" target="_blank">l10n.kde.org</a><br>
> ><br>
> > 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)<br>
> <br>
> Damned Lies looks like a good replace. But one thing I would miss, is <br>
> the ‘Compare Translations’ feature at <br>
> <a href="https://l10n.kde.org/dictionary/compare-translations.php" rel="noreferrer" target="_blank">https://l10n.kde.org/dictionary/compare-translations.php</a>. I don’t (need <br>
> to) use it very often, but when I do, it’s very useful.<br>
<br>
We could probably keep that<br>
<br>
> > * Use of our infrastucture<br>
> ><br>
> > 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<br>
> <br>
> I guess that’s OK for larger ‘KDE translation teams’, but for some <br>
> languages, what’s defining the ‘team’ is not the project (KDE software), <br>
> but the language. For example, for the two Norwegian languages, we have <br>
> a mailing list for discussing Norwegian translations, terminology etc. <br>
> for free software in general, i.e., *across* several translation <br>
> projects. And most of the members are not (active) translators at all; <br>
> they’re users – users interested in having a variety of free software in <br>
> their native language. IMO, this is much more useful than having siloed <br>
> mailing lists that KDE-specific, GNOME-specific, freedesktop-specific, etc.<br>
<br>
Yes, there's a balance to strike, but when/if those projects die, we're left with nothing, which is not good, and from what i can see looking at the links we have in l10n teams site, those projects die much more often than KDE.<br>
<br>
Cheers,<br>
  Albert<br>
<br>
<br>
<br>
<br>
</blockquote></div>