2018-01-07 23:24 GMT+02:00 Martin Landa <[email protected]>: > Hi all, > > 2018-01-07 22:03 GMT+01:00 Veronica Andreo <[email protected]>: >> 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. _______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
