Akademy meeting notes

[Yaron Shahrabani]

> I’m not sure what you mean by this comment, but I’m sorry if I gave the
>> impression that I’m not actually familiar with Weblate. I am a
>> translator of several projects that use Weblate, so I’ve have had plenty
>> of time to practice and use it. (Though I ended up using offline
>> translation instead, with a bunch of custom scripts to get things out of
>> and into Weblate.)
>>
>
> Familiar != well experienced, I know soccer.
>
>>
>>
>> > What are you talking about? Having suggestions from other projects,
>> > comments, TM and screenshots doesn't help you improve your QA?
>>
>> All that sounds good. And I get all that except screenshots (and
>> cross-language comments) from Lokalize. And the implementation in
>> Lokalize is vastly better than the one in Weblate. One important
>> difference is speed. In Lokalize, everything is instant. That means that
>> I can work fast/efficiently. In Weblate, every action takes at least a
>> second, often several seconds. That’s time that’s just wasted. Another
>> difference is the actual features. For example, in Weblate fuzzy strings
>> and suggestions from the translation memory don’t even have a (coloured)
>> diff view, so I can’t see what the changes are. That makes fixing
>> strings and using suggestions much harder and more time consuming, and
>> also lowers the quality I am able to obtain.
>>
>
> Four things:
>  - It doesn't scale.
>  - It's not portable nor cross platform.
>  - It's not straightforward although you truly believe it is.
>  - Diff is coloured.
>
>>
>> When it comes to screenshots, I doubt that the developers are going to
>> add screenshots *and keep them up to date*. That takes up very much
>> time. They often don’t even add message context to their strings, which
>> is both fast and easy. But the lack of screenshots isn’t really much of
>> a problem. I always test the applications at the same time, so I can see
>> how the strings look.
>>
>
> It's not only the developers' responsibility, the community can join and
> should join the effort.
>
>>
>> I can probably add a long list of tools (e.g. scripts) and features that
>> I use, if people really are interested, but I don’t have time tonight.
>> But just to mention a couple of things that I use:
>>
>> Whenever I finish a translation of a file or a module, I run a spell
>> check which lists all possibly misspelled words (‘posieve check-spell-ec
>> -slist’). Then I can quickly scan the list of words (or perhaps combine
>> it with a custom list of false positives) and spot any mistakes.
>>
>
> Hmmmm LanguageTool?
> I see it already supports Norwegian (both Bokmol and Nynorsk, it just
> doesn't appear on the main page).
>
>>
>> I also use the Pology ‘check-rules’ feature. We have implemented a large
>> set of rules (‘checks’ for common mistakes and deviations from our
>> linguistic guidelines). So I can just run ‘posieve check-rules
>> --skip-obsolete -slokalize’ (I of course have a shorter alias for this)
>> to let Pology test every string against this set of rules. And it
>> automatically opens a filtered list of the failed strings in Lokalize,
>> so I can quickly browse through them and fix them (or add a ‘skip-rule’
>> as a translator comment if the string needs an exception). This has been
>> a boon for the quality of the translations.
>>
>
> Implemented at translate-toolkit level, the project owners can configure
> that.
>
>>
>>
>> > OK, so let's discuss the alternative, checking out each and every
>> > screen and each and every dialog,
>>
>> Well, to ensure a proper translation, you really have to this anyway.
>> Weblate doesn’t help us there. IMO, testing a translation is extremely
>> important. I always find a bunch of (usually smaller) mistakes and
>> things that can be improved when I test the translation. I usually have
>> the application and Lokalize open at the same time.
>>
>
> On your phone on your way to work?
> I'm talking about contributing at scale and combining it with daily
> activities, this way you can ensure that someone who was pretty active as a
> teen can keep contributing as a working father.
>
>>
>>
>> > using each and every CLI option possible just to make sure I've see
>> > everything I can and then go and translate hoping I'll remember
>> > everything I saw, not to mention searching for words in the dictionary
>>
>> I’m not sure what you mean with ‘searching for words in the dictionary’.
>> But I use the translation memory feature in Lokalize, which
>> automatically lists similar strings and has colour coding to show how
>> the strings differ.
>>
>
> Even if you're using an external TM source it's not enough.
> Collaborative TM collects much more relevant data from lots of different
> sources.
>
>>
>> In addition, most translations in the PO files a pre-filled with a
>> suggestion, based on a compendium of other translations (in KDE and
>> other translation projects where I am active). So often I only have to
>> unfuzzy the string (‘Ctrl + U’) or make minor modifications (the
>> coloured diff view is extremely helpful here).
>>
> TM, Weblate does that too.
>
>>
>> For looking up spelling and conjugation (which is sometimes a bit
>> complicated in my language), I use a command-line dictionary.
>>
>
> Doesn't scale.
>
>>
>> I also use the translation memory *search* feature in Lokalize, which
>> can find all strings (across files) which contain a given word or phrase.
>>
>
> There is such feature in Weblate.
>
>>
>> For finding the correct terminology, I use a small script which suggest
>> the correct terminology based on other translations. I use it like this:
>>
>> $ term browse
>> browser → nettlesar
>> browse → bla; Bla gjennom
>> web browser → nettlesar
>> filesystem browser → filhandsamar; filsystemvisar
>> […]
>>
>
> Not on your phone on your way to work, doesn't scale.
> Does it integrate directly into Lokalize?
>
>>
>> It’s based on the excellent poterminology tool:
>>
>> http://docs.translatehouse.org/projects/translate-toolkit/en/latest/commands/poterminology.html
>>
>> I also use a tool that compare the frequency of words in the
>> translations (if I’m unsure if I should use translation A or translation
>> B, looking at the word frequencies is helpful).
>>
>
> Doesn't scale, feel free to suggest such feature to Weblate if you're
> missing it.
>
>>
>>
>> > and go and search for the string in other project when in doubt (not
>> > to mention the fact that if I want to do it on several different
>> > machines I need ,for each and every one of them, to prepare my
>> > environment, install the relevant tools, clone the repository, etc.),
>>
>> Oh. We also have an online dictionary of all the translations (for
>> projects that I maintain + a few other major projects). This makes it
>> very fast to look up translations. You can see it in action here:
>> https://huftis.org/kritikk/omsetjingsdb/nn/
>
>
> Available for Hebrew?
>
>>
>>
>> It preloads *all* the translations, so the page takes a few seconds to
>> load. But after that, looking up a source string or a translation is
>> almost instant.
>>
>>
>> > if you don't consider this procedure slow you're not looking at the
>> > right parameters when calculating the actual time spent on localization.
>>
>> I believe I take all this into consideration. That’s why I use Lokalize,
>> which IMHO is the best, fastest and most user-friendly editor (though I
>> haven’t looked to see if there are any other new offline PO editors
>> released lately) *plus* the other tools and scripts that help me provide
>> the best translations in the most efficient way.
>>
>> If other people have other tools that they use and find helpful in
>> translating, I would love to hear about them.
>>
>
> Again, doesn't scale, you can't possibly expect anyone to install all
> these tools along with their dependencies while getting them to know all
> the shortcuts you've done for yourself unless you're willing to release
> everything as a single open source repository and database to cover all the
> possible needs for translators (which in this case can make you a good
> potential competitor to the other platforms assuming you're also offering a
> web interface :) ).
>
> "best, fastest and most user-friendly" best depicts the doesn't scale
> claim due to defining something through your own perspective, I'm not
> saying it's not good I'm just saying that when combining different
> constraints/requirements there are more demands other than fast or
> user-friendly.
>
> I believe that the best possible tool is translating directly in context
> which means that if there was a tool that lets you point and click through
> localization it would be very helpful but the closest we can get to that is
> screenshots which in large complicated systems doesn't scale (unless you're
> combining the screenshot capturing process with your QA process and then it
> scales pretty well, it possible yet requires a very good QA automation
> skills).
>
> Regarding fast, we were talking about asynchronous localization method
> where you can simply skip on to the next string without waiting for the
> current one to finish saving, there are some difficulties with that but
> overall it's not impossible and other localization platforms are already
> doing that.
>
>>
>> Oh, that was just a joke. It was a reference to the *dove* analogy.
>> *Doves* and *cloud*, you know. Not a particular good joke, I admit. :)
>>
>
> Ohhh, sorry I didn't get that :)
>
>>
>>
>> >     I see your point, in that one can use Weblate as just a commentary
>> >     (annotation) system. That could work, though I would still prefer
>> >     metadata about translations to be stored in the translation files
>> >     or in
>> >     source code, so that they would be available for *all* tools, not
>> >     just one.
>> >
>> >
>> > It should work that way.
>>
>> It doesn’t. Weblate doesn’t export the commentary to the PO files.
>>
>
> You can suggest such a feature if you're missing it but the comments are
> pretty helpful and keeping the po files pretty lean.
>
>>
>>
>> > If this string is unclear you should change the string or add a
>> > satisfying explanation in the context,
>>
>> Yes, in the source code. Then it will be available for all translators
>> (and the developer reading the source code), no matter which tool they
>> use.
>>
>
> Both these systems doesn't solve that, I added a comment at the end.
>
>>
>>
>> > adding a comment in your locale's .po doesn't seem like the best
>> > practice I know (specifically because the knowledge is not shared with
>> > other teams, even if you don't believe it's relevant to them).
>>
>> I was thinking about language-specific strings. They belong in the PO
>> file.
>>
>
> Well, yet again, doesn't scale, sorry, I'm not going to look at all the
> other teams' PO files to find some reference.
>
>>
>>
>> >     Note that I’m not at all against having Weblate or a similar
>> >     system as
>> >     an *alternative*. I like that people can choose the editor they
>> want.
>> >     But the editor should ‘play nice’ with existing infrastructure and
>> >     standards.
>> >
>> >
>> > Isn't tight git integration good enough for you?
>> > Squashing commits to avoid garbage?
>>
>> I think squashing commits is a good thing (if you by this mean batch
>> committing a bunch of strings instead of one string at the time – the
>> latter would be very bad practice).
>>
>
> They are committed once at a time and squashed afterwards either
> automatically when configured or on demand when merging.
>
>>
>>
>> > Except for the commentary (which is public) what else do you consider
>> > bad practice from Weblate's side?
>>
>> Well, I use translator comments a lot. Both for information for other
>> translators and as ‘notes to future self’. I also use it to add
>> exceptions for the Pology ‘check-rules’ script. So basically, translator
>> comments in the PO files are very important. But if I upload a PO file
>> containing translator comments to Weblate and then download the PO file
>> again, all the comments are gone. Completely deleted. I consider that
>> extremely bad practice.
>>
>
> We can try and see why it happens and if there's a way to change it, if
> it's already implemented elsewhere it should be much of a problem.
>
>>
>>
>> And here’s one thing I don’t know about Weblate, but perhaps you can
>> tell me. When I edit a PO file with an offline editor, it adds/updates
>> the credits in the PO file header. The credits lines looks like this:
>>
>> # Karl Ove Hufthammer <karl at huftis.org>, 2008, 2015, 2016, 2019, 2020.
>>
>> Does Weblate do this too? The reason that I ask, is that I have seen
>> other online tools (e.g., Transifex and POEditor) that don’t, and that
>> even delete existing credits.
>>
>
> Both Weblate and Transifex were founded by open source developers,
> Weblate was founded by Michal Cihar, the developer of Gammu/Wammu,
> maintainer of PHPMyAdmin, translate-toolkit and many other,
> Transifex was founded by Dimitris Glezos, a well known Fedora contributor
> and activist.
>
> If you think the credit is lost you can report that for the sake of open
> source contribution, I can see why people can lose motivation over that.
>
>>
>> It’s not the *most* important feature, but all(?) offline tools supports
>> it, and I like that the translators are properly (and automatically)
>> credited in the files, and that I can see at a glance when the PO files
>> were updated (not just the most recent update). I also use it to create
>> a simple translation history graph.
>>
>
> Weblate does that.
>
>>
>>
>> Another thing I dislike is if the tool reformats the strings (i.e., with
>> other line-breaks) when saving. (Though Lokalize also does this if you
>> use the wrong settings.) What does Weblate do?
>>
> Same, sometimes I leave trailing or leading whitespace and when I move to
> the next string I'm seeing a message the the former string was modified.
>
>>
>>
>> >
>> >     Are you talking a feature to send info to Bugzilla about a string or
>> >     about a translation?
>> >
>> > Why not both?
>> > Misleading? Cumbersome? Typo? Just click the relevant button and a new
>> > Bugzilla tab will open with all the relevant details waiting to submit!
>> :)
>>
>> I very much like the ‘just click a button’ thing, but, well, Bugzilla is
>> extremely user-unfriendly. So I would prefer something simpler. I
>> remember there was talk about having a ‘Report Translation Error...’
>> feature in the ‘Help’ menu of all applications (just like the current
>> ‘Report Bug...’ feature). Perhaps on this list, or in Phabricator, or
>> somewhere deep in Bugzilla? But it never materialised, unfortunately. I
>> know – patches welcome … :)
>>
>
> I remember when Ubuntu had that, it brought lots of garbage.
> It can be quite useful but it has to be super specific and well guided.
> Usually when there were bugs reported about my translations I couldn't
> even see that because the reporter didn't add the Hebrew team for review.
>
> Thinking this over can actually lead to a very good design plan for such a
> feature when integrating with GitHub/GitLab or any other code management
> system, let's try and deepen the discussion somewhere else :)
>

Over 40K, it bounces from the list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20200930/8c7c9f11/attachment-0001.htm>