Akademy meeting notes

[Josep Ma. Ferrer]

Hello!

El 13/9/20 a les 14:48, Yaron Shahrabani ha escrit:
>
> YaronShahrabani
>
>     <DevOps - Hebrew translator>
>
>
>
> On Sun, Sep 13, 2020 at 1:26 PM Albert Astals Cid <aacid at kde.org
> <mailto: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.

I think each translation team must define if their translations will be
on Weblate or no, being "no" the default value. This will avoid any
configuration on the Weblate site for teams that don't need Weblate, and
save resources on the KDE side (sending each day all the changes on
translations files which nobody will use).

Please, keep in mind that there are some useful tools (e.g. Pology) that
work in a directory structure but not in an online translation solution.

Josep Ma. Ferrer

>
>
>     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 <http://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.
>
>