Le Fri, 12 Jan 2018 13:00:41 +0200, Maris Nartiss <maris....@gmail.com> a écrit :
> 2018-01-07 23:24 GMT+02:00 Martin Landa <landa.mar...@gmail.com>: > > Hi all, > > > > 2018-01-07 22:03 GMT+01:00 Veronica Andreo <veroand...@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 languages. 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. Moritz _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev