Akademy meeting notes

[Scott]

Added my moments on documentation and comparisons.
-Scott

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, September 13, 2020 12:48 PM, Yaron Shahrabani <sh.yaron at gmail.com> wrote:

> Yaron Shahrabani
>
>> <DevOps - Hebrew translator>
>
> On Sun, Sep 13, 2020 at 1:26 PM Albert Astals Cid <aacid at kde.org> wrote:
>
>> Here are the notes from the Akademy meeting.
>>
>> If you have something to follow up/comment i guess start new threads? Or answer this changing the subject?
>>
>> Cheers,
>> Albert
>>
>> * 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
>
> Weblate supports them both.
>
>> - We understand that using a web translation solution is potentially easier for newcomers
>
> Depending on the workflow, it could ease the regular workflow also for very experienced contributors (Localizing from your smartphone on the daily commute).
>
>> - Having two systems is a bit incovenient because it makes documentation harder
>
> True that.

I am happy to create and maintain any Weblate documentation once things like approval workflow are decided upon. Please link me to ticket if one already exists for creating documentation. Fortunately because using Weblate is relatively simple to use, documentation would be relatively simple.

>> - It will not be possible to "commit a translation" from the web system unless you have commit access in svn
>
> I think that it will be easier to implement it using a centralized solution like LDAP/SAML which are already implemented.
>
> I'm sorry I couldn't attend and I know it's a little bit too late for that but I want to support the web localization solution in order to revive the Hebrew team and possibly many other teams.
>
> Anything I can do to help bring this suggestion to life (I'm a DevOps engineer and I know how to deploy and maintain Weblate)?
>
> BTW, There's an option to configure Weblate so it won't interrupt current workflow so that if your team prefers the direct SVN method you are free to continue doing so, it just requires disabling access to this specific language for editing (the changes will appear in Weblate but nobody will be able to edit them or suggest), having the strings synced with Weblate can possibly assist other translators that use Weblate and this language as a reference.
>
>> It's important that if we implement this, people that are using their own web based translation systems start using KDE's one
>
> Yes, that's pretty common.
>
>> There's several factors that influence the tool choice: quality of translations, easiness of contribution, efficiency while translating, quantity of translations.
>
> Quality of translations can be configured by the team leader, I can give translation rights to specific users or allow all of my team members to suggest but I'm the only one who can approve.
> Furthermore, there's an option to upload screenshots and tag the strings so it should allow the translator to better understand the context.
> Quantity - since there's no contradiction between the old and the new platform it should increase quantity because everyone gets their prefered workflow option.
>
>> Different systems have different strenghts/weaknesses.
>
> Which other systems?

To my knowledge all tools that are apples to apples to Weblate in that they allow submitting suggestions via a browser, are open source and be self hosted w/o license fees (Pootle, Zanata) are dead. Pootle hasn't had a release in 3 years and asked the Monero localization team if we were interested in taking over when we asked about some bugs as they no longer want to own it. Zanata is in a similar state of abandonment. Other solutions like Transifex don't allow self hosting which is presumably a requirement given elsewhere KDE has said they want to own / self host things as small as Telegram <-> Matrix chat client bridges and discouraged third party based bridges which would have taken maybe 10 minutes. Weblate really is to my knowledge the only notably active tool that would meet KDE's needs. Not to mention Weblate is adopted by notable FOSS projects like Fedora, OpenWrt, and Godot Engine who are likely to contribute in some form back to improving Weblate.

> I'd love to address more questions if there are any.
>
>> We need to provide a clear path of what needs to be done in order for KDE to be able to provide a web based translation system
>
> I'll be happy to assist.
>
>> *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)
>>
>> * Scripty improvements
>>
>> Scripty code is a mix of various scripts in various languages written over more than a decade. It's not easy to maintain, we disccused several plans to improve it, both short and long term.
>>
>> * Documentation
>>
>> We discussed that documentation needs improvement, it's spread in several places so it's not always easy for a newcomer to know what to read.
>>
>> There's differnet needs translators need to do, so it would be good if we could have different entry points in the documentaiton for each task.
>>
>> The Lokalize documentation is not very good it seems (but we need to be careful, Lokalize is not used only to translate KDE so we need to make sure we don't introduce too much "how to translate KDE" references in it)
>>
>> * 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
>>
>> * 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20200913/968d1eeb/attachment-0001.htm>