Akademy meeting notes

[Yaron Shahrabani]

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.

> - 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?

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/d5a12b6f/attachment.htm>