Akademy meeting notes
sh.yaron at gmail.com
Mon Sep 21 21:33:44 BST 2020
<DevOps - Hebrew translator>
On Mon, Sep 21, 2020 at 8:38 PM Karl Ove Hufthammer <karl at huftis.org> wrote:
> Yaron Shahrabani skreiv 20.09.2020 20:46:
> > Regarding second class citizens: I would never advocate against a
> > collaborative technology just because I got used to something more
> > conservative.
> > 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
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.
What are you talking about? Having suggestions from other projects,
comments, TM and screenshots doesn't help you improve your QA? What else do
you need to get the job done?
OK, so let's discuss the alternative, checking out each and every screen
and each and every dialog, 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 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.), 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 don't understand what you were saying about *cloud computing*, how is it
different from any other server? Does it really matter if we call it cloud
computing or hosting servers? This is a centralized solution to manage an
otherwise pretty messy job with lots of different tools and systems to use
while localizing, only if you want to use the same kind of support you're
getting from the centralized solution, otherwise you can just rely on the
information you have which in most cases can be just fine for the job.
> ¹ I know the plan is to have Weblate being optional. That’s good.
> > I also believe that having a single interface for relevant commentary,
> > screenshots, suggestions, TM and glossary will improve the overall
> > translation quality and quantity while not affecting the more
> > conservative ways, BTW, there's no reason to deny Weblate as a
> > commentary system, it's not like it evades privacy, you can choose to
> > use it specifically for discussions and nothing more or at least
> > subscribe to the notifications to know what's going on.
> 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.
If this string is unclear you should change the string or add a satisfying
explanation in the context, 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
> 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
Isn't tight git integration good enough for you?
Squashing commits to avoid garbage?
Except for the commentary (which is public) what else do you consider bad
practice from Weblate's side?
> My ideal online translation system (for people who prefer to use an
> online client) is one which would interact *directly* with Git/SVN,
> i.e., just pull the latest PO files from Git/SVN, commit the result when
> the user saves (or at the end of the session), and store all data in the
> actual PO file (i.e., as translator comments). There would be no need
> for a separate database of strings, like Weblate uses. It would be just
> like another PO editor; the only difference would be that you would
> access it using your browser instead of accessing it through a normal
> application. (I’m thinking of something similar to this, non-free, I
> think, online PO editor, only with Git/SVN integration:
I don't want to urge you to read the documentation because it's pretty
tedious (you can if you want to) but you can trust me when I say that it
doesn't go far from the method you described.
Weblate has a public repository of you changes and they are pushed back to
the original location upon request from the project maintainer, all your
changes are saved in a local git until submitted so it's public and
accessible all along plus I can't remember how the conflict management
works but I remember it works pretty well (it had many issues in the past).
> > I think we can suggest a feature to send the relevant info to Bugzilla
> > to allow you to open a bug about that string (using the interface, not
> > automatically, maybe even develop such feature).
> 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! :)
> Karl Ove Hufthammer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-i18n-doc