Akademy meeting notes

[Karl Ove Hufthammer]

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


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

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.

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.

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.


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


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

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

For looking up spelling and conjugation (which is sometimes a bit 
complicated in my language), I use a command-line dictionary.

I also use the translation memory *search* feature in Lokalize, which 
can find all strings (across files) which contain a given word or phrase.

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
[…]

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


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

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.


> 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. :)


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


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


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


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


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


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.

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.


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?


>
>     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 … :)


-- 
Karl Ove Hufthammer