<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Albert Astals Cid skreiv 04.09.2024
      00:08:<br>
    </div>
    <blockquote type="cite" cite="mid:1878872.B6eNgpy4FR@xps15">
      <pre><blockquote type="cite"
style="overflow: unset; height: unset;                    background-image: url(chrome://messenger/skin/overrides/arrow-down-12.svg); padding-block: .5ex;                    background-repeat: no-repeat; background-position-x: 2px; background-position-y: .4ex; background-size: 1em;"><pre
      class="moz-quote-pre" style="display: inline;" wrap="">
[1] <a class="moz-txt-link-freetext"
      href="https://community.kde.org/Akademy/2024/Tuesday"
      moz-do-not-send="true">https://community.kde.org/Akademy/2024/Tuesday</a>

Depending on the remote joining options for Akademy BoF in general, it may
be available to remote attendees too.
</pre></blockquote><pre class="moz-quote-pre" wrap="">Some folks complained they could not make it Tuesday so we've moved it to 
Monday (same room and time).</pre></pre>
    </blockquote>
    <p>I’m not (physically) at Akademy, and won’t be able to attend, but
      I have a suggestion for something to discuss (either at the BoF or
      on this mailing list): moving from SVN to Git.</p>
    <p>When the rest of KDE moved to Git, the translators wanted to stay
      with SVN. I seem to recall (though haven’t bothered to check the
      archives…) that at least part of the reason was that (in 2010) Git
      was new, unfamiliar technology which the translators were
      reluctant to learn. Well, now in 2024, Git is very familiar to
      most developers (potential translators), while SVN is the old,
      unfamiliar technology. So perhaps the time is ripe to make the
      change?</p>
    <p>Some advantages:</p>
    <p>* A tool familiar to many people – easier to get new translators?<br>
      * Easy access to the history via invent.kde.org.<br>
      * People can very easily create merge requests to contribute<br>
        translations (don’t need to have SVN write access or send<br>
        patch files via email).<br>
      * All Git features available. For example, it’s quick and easy<br>
        to look up when a certain translation or msgid was added.<br>
    </p>
    <p>Some disadvantages:</p>
    <p>* People who don’t know Git would need to learn a new tool.<br>
      * Changes to the workflow.<br>
      * The conversion process…</p>
    <p><br>
    </p>
    <p>I have some thoughts about the structure of the Git repo(s),
      based on my experience with other Git repos for translations:<br>
      <br>
    </p>
    <p>There should be *one* Git repo for each language. Don’t put all
      languages in one repo. (This is slow and takes up much disk space
      for the translators.)</p>
    <p><br>
    </p>
    <p>No Git branches. Have each branch as a folder, like we have now.
      But we can simplify a few things that are the way there are only
      because of version control system used (the ‘trunk’ and ‘branches’
      top-level ‘SVN branches’). Suggested top-level structure:</p>
    <p>stable/l10n-kf5<br>
      stable/l10n-kf6<br>
      …<br>
      trunk/l10n-kf5<br>
      trunk/l10n-kf6<br>
      …<br>
      trunk/summit</p>
    <p>Then the translations will be on the same level (instead of the
      stable ones being on level further down in ‘branches/stable’). An
      equally good (better?) alternative would be to make *all* the
      translations folders top-level, e.g., ‘stable-l10n-kf5’ instead of
      ‘stable/l10n-kf5’. This would be faster to navigate.<br>
    </p>
    <p><br>
    </p>
    <p>We would want to keep *all* the history for each language
      (including the folder structure). This is a ‘fun’ challenge, as
      the files have been moved around a lot. And the PO files haven’t
      always had a consistent location *within* a revision. For example,
      for revision 5686 (back in 1998), I found German translation files
      in all these locations:<br>
      <br>
      kde/trunk/kdenetwork/po/de/kmail.po<br>
      kde/trunk/klyx/po/de.po<br>
      kde/trunk/kde-i18n/de/messages/kdebase/kcminfo.po</p>
    <p>But all this should be solvable by using some clever regexps.</p>
    <p>There are also languages that have changed language codes over
      time (e.g., Norwegian Nynorsk, which now has language code ‘nn’,
      used to have the language code ‘no_NY’). This is also easy to
      handle.<br>
    </p>
    <p><br>
    </p>
    <p>Someone needs to the conversion. :(<br>
      An adjust all the tooling to use the new infrastructure. :(</p>
    <p>I have *some* experience converting SVN repos to Git repos and am
      willing to both help and test things. But I think we need someone
      (with direct access to the SVN server?) preferably familiar with
      KDE’s SVN and Git infrastructure (and the previous SVN to GIT
      conversion?) and who is willing to do the main work.</p>
    <p><br>
    </p>
    <p>That is, if we *want* to do the conversion.<br>
      I think it will improve things,<br>
      but what do you other translators think?<br>
    </p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Karl Ove Hufthammer</pre>
  </body>
</html>