<div dir="ltr"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 16, 2020, 14:43 Josep Ma. Ferrer <<a href="mailto:txemaq@gmail.com" target="_blank">txemaq@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
El 13/9/20 a les 14:48, Yaron Shahrabani ha escrit:<br>
><br>
> YaronShahrabani<br>
><br>
>     <DevOps - Hebrew translator><br>
><br>
><br>
><br>
> On Sun, Sep 13, 2020 at 1:26 PM Albert Astals Cid <<a href="mailto:aacid@kde.org" rel="noreferrer" target="_blank">aacid@kde.org</a><br>
> <mailto:<a href="mailto:aacid@kde.org" rel="noreferrer" target="_blank">aacid@kde.org</a>>> wrote:<br>
><br>
>     Here are the notes from the Akademy meeting.<br>
><br>
>     If you have something to follow up/comment i guess start new<br>
>     threads? Or answer this changing the subject?<br>
><br>
>     Cheers,<br>
>       Albert<br>
><br>
><br>
><br>
>     * Web translation solution<br>
><br>
>     Unfortunately none of the strong proponents for it attended the<br>
>     meeting<br>
><br>
>     - The direct svn/git solution will stay to make sure our current<br>
>     users keep happy<br>
><br>
> Weblate supports them both. <br>
><br>
>     - We understand that using a web translation solution is<br>
>     potentially easier for newcomers<br>
><br>
> Depending on the workflow, it could ease the regular workflow also for<br>
> very experienced contributors (Localizing from your smartphone on the<br>
> daily commute).<br>
><br>
>     - Having two systems is a bit incovenient because it makes<br>
>     documentation harder<br>
><br>
> True that.<br>
><br>
>     - It will not be possible to "commit a translation" from the web<br>
>     system unless you have commit access in svn<br>
><br>
> I think that it will be easier to implement it using a centralized<br>
> solution like LDAP/SAML which are already implemented.<br>
><br>
> I'm sorry I couldn't attend and I know it's a little bit too late for<br>
> that but I want to support the web localization solution in order to<br>
> revive the Hebrew team and possibly many other teams.<br>
><br>
> Anything I can do to help bring this suggestion to life (I'm a DevOps<br>
> engineer and I know how to deploy and maintain Weblate)?<br>
><br>
> BTW, There's an option to configure Weblate so it won't interrupt<br>
> current workflow so that if your team prefers the direct SVN method<br>
> you are free to continue doing so, it just requires disabling access<br>
> to this specific language for editing (the changes will appear in<br>
> Weblate but nobody will be able to edit them or suggest), having the<br>
> strings synced with Weblate can possibly assist other translators that<br>
> use Weblate and this language as a reference.<br>
<br>
I think each translation team must define if their translations will be<br>
on Weblate or no, being "no" the default value. This will avoid any<br>
configuration on the Weblate site for teams that don't need Weblate, and<br>
save resources on the KDE side (sending each day all the changes on<br>
translations files which nobody will use).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There's no reason to opt in without a request, it's pretty easy to configure.</div><div dir="auto"><br></div><div dir="auto">The changes<span class="gmail_default" style="font-family:tahoma,sans-serif"> 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.</span></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Please, keep in mind that there are some useful tools (e.g. Pology) that<br>
work in a directory structure but not in an online translation solution.<br></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">What about collaboration? Suggestions? Screenshots for context?</div><div style="font-family:tahoma,sans-serif" class="gmail_default">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.</div><div style="font-family:tahoma,sans-serif" class="gmail_default">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.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Josep Ma. Ferrer<br>
<br>
><br>
><br>
>     It's important that if we implement this, people that are using<br>
>     their own web based translation systems start using KDE's one<br>
><br>
> Yes, that's pretty common. <br>
><br>
><br>
>     There's several factors that influence the tool choice: quality of<br>
>     translations, easiness of contribution, efficiency while<br>
>     translating, quantity of translations.<br>
><br>
> Quality of translations can be configured by the team leader, I can<br>
> give translation rights to specific users or allow all of my team<br>
> members to suggest but I'm the only one who can approve.<br>
> Furthermore, there's an option to upload screenshots and tag the<br>
> strings so it should allow the translator to better understand the<br>
> context.<br>
> Quantity - since there's no contradiction between the old and the new<br>
> platform it should increase quantity because everyone gets their<br>
> prefered workflow option.<br>
><br>
>     Different systems have different strenghts/weaknesses.<br>
><br>
> Which other systems?<br>
><br>
> I'd love to address more questions if there are any.<br>
><br>
><br>
>     We need to provide a clear path of what needs to be done in order<br>
>     for KDE to be able to provide a web based translation system<br>
><br>
> I'll be happy to assist. <br>
><br>
><br>
><br>
>     * <a href="http://l10n.kde.org" rel="noreferrer noreferrer" target="_blank">l10n.kde.org</a> <<a href="http://l10n.kde.org" rel="noreferrer noreferrer" target="_blank">http://l10n.kde.org</a>><br>
><br>
>     We're hoping to eventually simply kill it. It uses old PHP (the<br>
>     code is relatively bad). Replace it with Damned Lies from gnome<br>
>     (which provides some other interesting functionality like file<br>
>     assignments)<br>
><br>
><br>
>     * Scripty improvements<br>
><br>
>     Scripty code is a mix of various scripts in various languages<br>
>     written over more than a decade. It's not easy to maintain, we<br>
>     disccused several plans to improve it, both short and long term.<br>
><br>
><br>
>     * Documentation<br>
><br>
>     We discussed that documentation needs improvement, it's spread in<br>
>     several places so it's not always easy for a newcomer to know what<br>
>     to read.<br>
><br>
>     There's differnet needs translators need to do, so it would be<br>
>     good if we could have different entry points in the documentaiton<br>
>     for each task.<br>
><br>
>     The Lokalize documentation is not very good it seems (but we need<br>
>     to be careful, Lokalize is not used only to translate KDE so we<br>
>     need to make sure we don't introduce too much "how to translate<br>
>     KDE" references in it)<br>
><br>
><br>
>     * Use of our infrastucture<br>
><br>
>     We need to try to make teams use our infrastructure for things as<br>
>     mailing lists, team guidelines, etc. Because we are sure our<br>
>     infrastructure will be maintained "forever", and sometimes<br>
>     external ones are not so stable/maintained<br>
><br>
><br>
>     * Move data files over to application repositories<br>
><br>
>     We agreed that moving the data files over application repositories<br>
>     makes sense. This way on the svn we only have things whose<br>
>     translations are done via po files. Will need to contact<br>
>     developers to convince them it's a good thing too :)<br>
>     Unrelated to that we need to improve discoverability of which<br>
>     applications have translatable data files.<br>
><br>
><br>
</blockquote></div></div></div>
</div>