[GRASS-dev] [release planning] 7.4.0

[Maris Nartiss]

2018-01-07 23:24 GMT+02:00 Martin Landa <landa.martin at gmail.com>:
> Hi all,
>
> 2018-01-07 22:03 GMT+01:00 Veronica Andreo <veroandreo at gmail.com>:
>> Just out of curiosity: Why not use transifex also for Latvian? Is there any
>> particular reason for that?
>
> I agree, to exclude LV from trasifex is not systematic approach once
> we agreed that we will use transifex...
>
> Ma
I somehow, as a current translator of GRASS to Latvian, don't remember
agreeing for this.

I fail to see any benefit of using web-based translation tools. Yes, I
am familiar with Transifex and Launchpad, also with KBabel, Lokalize
and fixing raw po files. I have been working as a coordinator of KDE
Latvian "team" since 2005, translating QGIS and various smaller
projects. And still I fail to see why moving to web based tool would
be beneficial.

Translating with a web interface is just a joke. Slow and cumbersome.
Not convenient for fast review of large amount of strings. No
scripting abilities. No diff support. No possibility to reject
contributions. KDE project as whole rejected all translation work done
in Launchpad (due to extremely low quality) before Ubuntu guys dropped
KDE from Launchpad.
Transifex still is showing wrong labels for plural form strings for
Latvian language. I reported it in 2015 and their answer was "change
string order in the file". (Really?!?) Thus anyone using web interface
will provide wrong translations for Latvian language.
"Easier to contribute" argument is also not solved by moving to web
platform, as it still depends on people. I got access to translate one
project on Transifex only after it was removed from my company
production servers as being obsolete. Yes, I submitted my translated
po file, but the fact that we managed to translate, integrate, test,
deploy to production and replace with different component all before
my request to add language and assign me rights to translate was
fulfilled speaks on its own.

QGIS moved to Transifex some time a go. Number of new contributors to
Latvian language due to "it is easier to contribute": 0. Keep in mind
– contrary to GRASS GIS, QGIS is widely used in Latvia, including some
(millions € worth) governmental IT projects, thus one could expect
large number of contributors; Recently a new issue was identified (see
Qgis-tr Tue Jan 9 15:16:15 PST 2018) – it is hard to track
contributors and thus list them in credits; Following multiple
branches is still unsolved.

KDE SC (number of strings approaches 200k, comparing to GRASS shy 15k)
is still pure po+svn workflow (with teams being free to use anything
as they wish as long as final output is a po file commit to svn). So
far all proposals for global migration have died out (example:
https://marc.info/?l=kde-i18n-doc&m=135873075615507&w=2); The Summit
approach of KDE SC is worth of exploring – so far it is the best
solution for tracking multiple branches simultaneously. Still Summit
plays off only for really active teams.

Finally – I fail to see any problem for skipping *_lv.po files as long
as data exchange with Transifex is scripted (or I decide to move to
ArcGIS). I'm not blocking others of using Transifex workflow, if it
feels appealing for someone. Yes, that means that I'll have to do all
pot->po merge dance for Latvian language and I'm fine with it.

I hope I clarified a bit.
Māris.