i18n BoF at Akademy 2024 (9th/Monday, 10:00, Room 1)

[Karl Ove Hufthammer]

Albert Astals Cid skreiv 04.09.2024 00:08:
>> [1]https://community.kde.org/Akademy/2024/Tuesday
>>
>> Depending on the remote joining options for Akademy BoF in general, it may
>> be available to remote attendees too.
> Some folks complained they could not make it Tuesday so we've moved it to
> Monday (same room and time).

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.

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?

Some advantages:

* A tool familiar to many people – easier to get new translators?
* Easy access to the history via invent.kde.org.
* People can very easily create merge requests to contribute
   translations (don’t need to have SVN write access or send
   patch files via email).
* All Git features available. For example, it’s quick and easy
   to look up when a certain translation or msgid was added.

Some disadvantages:

* People who don’t know Git would need to learn a new tool.
* Changes to the workflow.
* The conversion process…


I have some thoughts about the structure of the Git repo(s), based on my 
experience with other Git repos for translations:

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.)


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:

stable/l10n-kf5
stable/l10n-kf6
…
trunk/l10n-kf5
trunk/l10n-kf6
…
trunk/summit

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.


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:

kde/trunk/kdenetwork/po/de/kmail.po
kde/trunk/klyx/po/de.po
kde/trunk/kde-i18n/de/messages/kdebase/kcminfo.po

But all this should be solvable by using some clever regexps.

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.


Someone needs to the conversion. :(
An adjust all the tooling to use the new infrastructure. :(

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.


That is, if we *want* to do the conversion.
I think it will improve things,
but what do you other translators think?


-- 
Karl Ove Hufthammer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20240906/61a3ff41/attachment.htm>