Akademy meeting notes

[Akash Rao]

! (surprised)

On Wed, 30 Sep 2020 at 12:36, Yaron Shahrabani <sh.yaron at gmail.com> wrote:

>
> 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/20201001/3c187423/attachment-0001.htm>