Akademy meeting notes

Yaron Shahrabani sh.yaron at gmail.com
Thu Sep 24 07:36:14 BST 2020

On Tue, Sep 22, 2020 at 10:36 PM Karl Ove Hufthammer <karl at huftis.org>

> Yaron Shahrabani skreiv 21.09.2020 22:33:
> >
> >     > Obsolescence of old technologies is how most of us live (assuming
> >     > you're reading this message through the internet instead of
> >     using doves).
> >
> >     I love new and better technology! :)
> >
> >     I think our difference in opinion is partly caused by what we
> >     perceive
> >     as the ‘obsolete’ or the ‘better’ technology. For me, translating in
> >     Weblate is so incredible slow compared to translating in Lokalize
> >     (and
> >     the user interface of Weblate is IMHO much more confusing), and I
> >     have
> >     access to so few tools in Weblate that help me do proper QA, so
> >     having¹
> >     to use Weblate is like moving *backwards* in technology. Or, using
> >     your
> >     analogy, it would be like being forced to use doves for communicating
> >     instead of e-mail, because doves is the new, exciting technology
> >     (*cloud
> >     computing*).
> >
> >
> > Guess what, the same goes for me and soccer, I guess it happened
> > because I didn't practice, I can assure you that just like me you
> > weren't a Linux expert the first time you touched a computer, not
> > surprising.
> 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.

> But just to be extra clear: It’s fine if you or other prefer Weblate as
> an editor. I have not any objection at all to people using whatever tool
> they feel work best for them. Quite the opposite; I think a plurality of
> tools (which competes on features and user-friendlyness) is a *good*
> thing. What I do object to, is 1) if choice is taken away from us, or 2)
> a tool is implemented which doesn’t play nice with other tools, e.g.,
> one which makes lossy changes to PO files (like Weblate does, in my
> experience – see later comments).
> > What else do you need to get the job done?
> 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

> > 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

> 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

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

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.

> > I don't understand what you were saying about *cloud computing*, how
> > is it different from any other server?
> 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 :)

> --
> Karl Ove Hufthammer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20200924/a6094cac/attachment-0001.htm>

More information about the kde-i18n-doc mailing list