[GRASS-dev] [release planning] 7.4.0

Moritz Lennert mlennert at club.worldonline.be
Fri Jan 12 04:27:39 PST 2018

Le Fri, 12 Jan 2018 13:00:41 +0200,
Maris Nartiss <maris.gis at gmail.com> a écrit :

> 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 like Transifex and the idea that it potentially allows anyone to
easily to a translate a day without having to download the source code.

I do understand Maris' argument, however, and agree that Transifex'
interface does not make translation easier for someone who knows how to
handle the appropriate files. And I am sensitive to the argument that
we do not have an active translation community.

Maybe we should conduct a survey on the relevant mailing lists, but if
the whole Transifex migration has as only outcome that those who
translated in text before now have to use the web interface, I agree
that this risk being slightly counter-productive.

On the other hand, once the Transifex workflow is worked out, it would
allow us to campaign for more translaters offering them a very easy
access. I hear Maris' info about the none-existing effect on QGIS
translation, but would be interested if this is also true for other

In any case, I think we should keep things flexible and allow those
that want to to use a different workflow than the web-based interface,
at least on a language-by-language basis.


More information about the grass-dev mailing list