Concerning the gnome-2-32 branch of gnome-screensaver
Hello, I have an insignificant question, why Damned Lies generates stats for a non-existing branch of gnome-screensaver? The gnome-2-32 branch does not exist in GIT, someone should fix this. :) Take care, Žygis ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Concerning the gnome-2-32 branch of gnome-screensaver
2010-10-19 18:32 keltezéssel, Žygimantas Beručka írta: Hello, I have an insignificant question, why Damned Lies generates stats for a non-existing branch of gnome-screensaver? The gnome-2-32 branch does not exist in GIT, someone should fix this. :) There was an e-mail about creation of that branch, but it seems to be deleted since then. I added the gnome-2-30 branch to the gnome-2-32 stats page, thanks for the heads up! Regards Gabor Kelemen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
xml errors in documentation
Hi language team coordinators (Sorry for writing to the i18n list, but I think this is the easiest way to reach every language - the alternative being making lots of bug reports) This is a breakdown of every xml error in every translated documentation string in GNOME for those languages that have reasonable (> around 10%) coverage of the documentation. More precisely, every message where the English string is valid xml, but the translation is not. You may want to fix them as this probably means the messages are not displayed correctly in the help documents. Here's the list of numbers of errors for each language (if it's zero, ignore this :)): ./eu/summary.txt:Total errors 0 ./ja/summary.txt:Total errors 2 ./el/summary.txt:Total errors 3 ./gl/summary.txt:Total errors 22 ./ko/summary.txt:Total errors 9 ./it/summary.txt:Total errors 6 ./de/summary.txt:Total errors 14 ./zh_CN/summary.txt:Total errors 27 ./sv/summary.txt:Total errors 1 ./es/summary.txt:Total errors 19 ./fr/summary.txt:Total errors 22 ./en_GB/summary.txt:Total errors 0 ./fi/summary.txt:Total errors 25 ./pt_BR/summary.txt:Total errors 8 ./ru/summary.txt:Total errors 10 ./uk/summary.txt:Total errors 8 ./cs/summary.txt:Total errors 3 ./bg/summary.txt:Total errors 3 ./hu/summary.txt:Total errors 4 ./ca/summary.txt:Total errors 5 ./pt/summary.txt:Total errors 0 ./da/summary.txt:Total errors 9 The total number of errors is 182. The specific location of each error can be found by consulting the text files located here (note that some browsers may assume the wrong encoding; in that case you may wish to download the file): http://www.student.dtu.dk/~ashj/documentation-errors/ The xml checks were performed with the utility gtxml from pyg3t (in case you want to run your own xml checks subsequently): https://launchpad.net/pyg3t Best regards Ask Hjorth Larsen Danish translation team ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Moduleset Reorganization vs. L10N
2010/10/18 Dimitris Glezos : > On Mon, Oct 18, 2010 at 1:12 PM, Kenneth Nielsen > wrote: >> The solution of having a translations only copy of a module in gnome >> git, combined with some sort of automatic syncing back and forth, >> seems to a good solution for the module maintainers that don't mind >> having this sort of solution. > > I'm not sure how well this will work. The developer still needs to > sync between the trees, and in the past developers found this very > frustrating at times. An example is when a developer updates all PO > files with new strings and after this he pulls translations from the > translation branch. The merge is a nightmare (since git does a git > merge instead of a msgmerge). > > The feedback we received so far is that viable solutions are two: a) > pull&push straight to the master branch and b) not push anywhere, just > "upload" the files somewhere and the developer will fetch them when he > needs to. > >> In terms of translators this will mean >> that they can work the way they do now, so this should automatically >> be ok for translators*. Since it is almost an implementational >> freebie, is should be ok to have this as the base solution, and then >> after that determine if we want to add something else. >> >> So at this point, can we agree that this can be ONE acceptable >> solution? Then we could start working setting up the framework for it >> and actually implement it for the modules that are ok with it. > >> Then we can afterwards continue discussing whether we should/need to >> add an offer for a external translation framework that is also GNOME >> approved (e.g. Transifex, Launchpad ,). > > I like this step-by-step, build-on-what-we-have approach, it's very > wise and I usually follow it as well. Admittedly, though, it has a > (serious) disadvantage: It only accepts solutions which can build on > top of the current way of doing things. This impedes real/radical > change. Sometimes radically changing things is good (e.g. when you're > in a dead-end). > > Currently our way of working in GTP is "based on files hosted on a > VCS, namely git.gnome.org". The challenges are obvious and well > explained (although they hardly constitute a dead-end). My humble > suggestion is to take this opportunity to really think how effective > our way of doing things is. The plan behind Tx 1.0 was to move away > from "files hosted on a VCS" and go to "strings (not files) living in > a web app (not vcs) which can be imported/exported freely to files". > We had both independent projects as well as projects like GNOME behind > the decision. > > It was a really, REALLY hard decision, but we are confident that it's > the way things will work in the future and the way to go. Things like > upstream/downstream support, translation memory, consistency, > per-string suggestions/voting.. they're all possible now. The Q is > whether we want to take this opportunity to really re-think how we're > doing things, or if we're just going to shift this decision to e.g. 2 > years later. Sounds like a good BoF discussion for GUADEC. =) Well, I agree that we should think hard and long about this at some point, because we don't ever want to exclude ourselves from the opportunity to make radical changes. But I really really really don't think that the GNOME 3.0 cycle is the right time to do it. Regards Kenneth ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: xml errors in documentation
Am Mittwoch, den 20.10.2010, 00:36 +0200 schrieb Ask Hjorth Larsen: > This is a breakdown of every xml error in every translated > documentation string in GNOME Thanks a lot. Fixed for cs. > The xml checks were performed with the utility gtxml from pyg3t (in > case you want to run your own xml checks subsequently): > https://launchpad.net/pyg3t Naive idea: Could something similar could run on l10n.gnome.org and display an error on the website (or already when uploading it)? andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: xml errors in documentation
El mié, 20-10-2010 a las 02:23 +0200, Andre Klapper escribió: > > The xml checks were performed with the utility gtxml from pyg3t (in > > case you want to run your own xml checks subsequently): > > https://launchpad.net/pyg3t > > Naive idea: Could something similar could run on l10n.gnome.org and > display an error on the website (or already when uploading it)? Yeap, that would be awesome. > > andre -- Jorge González González Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: xml errors in documentation
El mié, 20-10-2010 a las 00:36 +0200, Ask Hjorth Larsen escribió: > Hi language team coordinators > > (Sorry for writing to the i18n list, but I think this is the easiest > way to reach every language - the alternative being making lots of bug > reports) > > This is a breakdown of every xml error in every translated > documentation string in GNOME for those languages that have reasonable > (> around 10%) coverage of the documentation. More precisely, every > message where the English string is valid xml, but the translation is > not. You may want to fix them as this probably means the messages are > not displayed correctly in the help documents. Thanks a lot, "es" fixed. However most of the errors came from epiphany, where I replaced ... with … apparently xml doesn't like it. Cheers. -- Jorge González González Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n