Akademy meeting notes

[Luna Jernberg]

Had some time to read this thread today, and all looks good, looking
forward to a System liked Damned Lies or Weblate, as i have been a bit
scared myself to contribute to Swedish translations of KDE, as i have not
been brave enough to send a personal email, it would be easier to just log
in to a system and start translating or reserve a project to help with

On Thu, Sep 17, 2020 at 12:24 PM Yaron Shahrabani <sh.yaron at gmail.com>
wrote:

>
>
> On Wed, Sep 16, 2020, 14:43 Josep Ma. Ferrer <txemaq at gmail.com> wrote:
>
>> 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).
>>
>
> There's no reason to opt in without a request, it's pretty easy to
> configure.
>
> The changes are handled specifically, each and every change is a pull
> request, you can select the branch, it doesn't have to be master and you
> can squash them in to a single PR, either per language or per period.
>
>>
>> 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.
>>
>
> What about collaboration? Suggestions? Screenshots for context?
> Using offline tools makes the translators a bunch of individuals doing
> some work, an open source web interface can lead to a true collaborative
> work in many aspects.
> For example, you can ask a question about what a certain string means and
> you can get an answer from a translator of another team or even ask to add
> a screenshot if possible.
>
> It's a different approach, not all TM tools are created equal and I
> understand that some of you experienced some of these tools but I assure
> you that Weblate is far different than Zanata or Launchpad, it truly works
> for the translator and has tight git integration (configurable), the
> overhead is decreased dramatically, just give it a try.
>
>>
>> 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.
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20200917/d6f88435/attachment-0001.htm>