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