Re: Some details of what happened (was: Re: HEADS-UP! URGENT! Major problem with translations for Hardy and Intrepid.)
În data de Du, 18-01-2009 la 03:12 +0800, Arne Goetje a scris: [snip] > Thanks for taking care of the translations, I know you do this > voluntarily and in your free time (I also work on several projects in > my > limited free time) and I appreciate it. > > Cheers > Arne If we could not automatically fix upstream translations do you think a periodic full translations check would help? I was thinking of creating a webpage similar to your reports and maybe add RSS feeds for each language. Below is the report based on Base pack: 2009-01-06 00:14:56 EET , but I would add a cron job to update such a page once every 2 weeks. http://l10n.ubuntu.tla.ro/rosetta-hardy-build/ What do you say? Kind regards, PS: the junky code is here: https://code.edge.launchpad.net/~adiroiban/+junk/rosetta-check -- Adi Roiban -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Some details of what happened (was: Re: HEADS-UP! URGENT! Major problem with translations for Hardy and Intrepid.)
Le dimanche 18 janvier 2009 à 03:12 +0800, Arne Goetje a écrit : > [...] Thanks for this precise feedback. I understand the problem now. Though, even if I agree it's a serious problem that must be fixed ASAP and avoided in the future, I'm still thinking you could have been a little cooler and more concerned about explaining what's going on - which is always a good method to get things done, in particular in free software. ;-) The house is not burning, but there's room for security improvements that we'll perform as soon as we can. > Wouldn't have helped in this case. The buggy translations came from > upstream. I agree that in some cases some locking would be useful. But > on the other hand, if upstream translations have problems, they can be > fixed faster for our users by using Launchpad (especially for stable > releases, which don't receive upstream updates anymore except for > regression and security fixes). Manual fixing can be useful, but it should be restricted to those special case, and be locked as a general rule. This would make our work much simpler and avoid much duplicate work (inherent to forks). In the current case, I guess that if we could automatically update translations to Launchpad when they're fixed upstream, fixing would be much straightforward for many packages (GNOME, KDE...). This cannot be done when there are modifications in Ubuntu: we have to deal with suggestions and so on... This was the sense of my remark. > I'm sorry if my initial mails sounded rude, that was not my intention. > However, I need to say that I wish to receive more feedback from you > guys, especially when it comes to language-pack testing. Whenever we > prepare new language-packs, they go to -proposed for stable releases and > need to be tested before released to -updates. Since I'm doing this I > haven't received any feedback if those proposed language-pack updates > were actually OK. I ended up testing some languages I'm roughly familiar > with myself (although I actually don't have the time for that, I'm > usually busy with development and bug fixing). Therefor the "please > report back" statement. About language pack updates, I've never even thought about reporting because I've not experienced issues with them. They have always improved translations without regressions that I know of. Getting feedback is not always a good sign, you know ! :-) > Since I am largely in charge of everything related to language support > in ubuntu on the Canonical side, I would really appreciate it to receive > feedback from you guys about problems or needed improvements in ubuntu > in regard to language support (input handling, fonts, rendering and also > translation related things). I don't have anything to do with Launchpad > though, so complaints about Launchpad need to be directed to the > Launchpad Translation Team via bug reports or questions. (They are > notoriously under-staffed, though.) As I said, Launchpad would've been the major improvement to bring to l10n teams. Dealing with French, other items are not a problem AFAIK. One important feature is adding full language packs to a system that was first installed without network. Last time I checked that, you needed to go to System->Admin->Language Support, and check the right box manually once you're connected to the network, which is not intuitive. Thus unexperienced users can end up using OO.o and Firefox in English. It could be nice if Update Manager (or PackageKit soon) checked for language packs the first time network is connected. (You asked for requests, here's one!) > Thanks for taking care of the translations, I know you do this > voluntarily and in your free time (I also work on several projects in > my > limited free time) and I appreciate it. Thanks for taking care of them too. I guess its not easy either, so let's make our common work more efficient. -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Some details of what happened (was: Re: HEADS-UP! URGENT! Major problem with translations for Hardy and Intrepid.)
Milan Bouchet-Valat wrote: > Wouldn't you mind giving us more details about the situation you > describe and its causes? You're suddenly coming and telling us that > everything is going to collapse and that we need to solve this horrible > list of bugs ASAP, without even explaining anything about it. Sorry for that. At the time of sending the initial mail we only knew we have a security problem at hand which involves buggy translations, which contain formatting placeholders where they shouldn't be. Only now I have some information at hand about what happened and will relay it to you. However, I'm just the messenger, so please don't shoot me. ;) > From what I've read and seen in the strings list, we're not in such an > emergency. Sure, some strings are not correct and can lead to crashes if > % jokers are present when they shouldn't. But this seems to have been > the case since the release of Hardy and Intrepid, so no need to stress > the teams like that. I really can't see your case here: what's new in > Hardy and Intrepid that can break anything? Where does those new strings > come from, and why can't they be reverted? We had a number of bug reports about applications crashing in certain circumstances in hardy and intrepid. Since these are stable releases, reports about arbitrary crashes get our attention and we try to fix those issues. If the issue is a security thread, it needs immediate attention and a fix ASAP. Only the bug about libxine crashing, pointed us into the right direction that buggy translations might be involved. ( https://bugs.launchpad.net/ubuntu/+source/xine-lib/+bug/290768 ) We noticed, that if a formatting placeholder is present in a translation where it shouldn't be, the application will read arbitrary data from the stack when this message is displayed. Reading arbitrary data from the stack is a security issue, which needs urgent attention. That's why we raised the flag. As a result, we turned on c-format checking in langpack-o-matic when generating language-packs. This will fail the build if such an error is present in the data. That's why all the buggy data needs to be fixed in Launchpad asap, or we won't get new language-packs. What we know is that these buggy translations came from upstream and got approved in Launchpad. In some cases later updates of those packages fixed the broken strings in the translations, however, they show up as 'suggests' in Rosetta and need to be approved manually. This has unfortunately not happened in many cases. Launchpad does check for c-format errors on translations, but: * it seems not to be enough ( https://bugs.launchpad.net/rosetta/+bug/317578 ) * some buggy translations predated the c-format flag and therefor didn't have one when they actually needed one * in some cases upstream did not set the c-format flag correctly To catch all possible erroneous translations we enforced the c-format flag on all messages when doing our analysis. The outcome ( http://people.ubuntu.com/~arne/langpack_errors/ ) has therefor some false positives. [Quote from Danilo to illustrate the problem] Indeed. c-format and no-c-format flags come from packaged templates, so it's up to them to decide on the proper usage (i.e. Launchpad doesn't have enough knowledge to insert them properly). Note that any approach to find every _potential_ problem would give us a lot of false-positives. I.e. "Insert % sign" is treated as space-padded "%s" modifier if marked as c-format string, but is definitely not one. To properly decide if any one case is a genuine problem or not, one would have to dive into the code that uses the string itself. [/Quote] > Anyway, I think I'd express quite accurately the feeling of many l10n > teams members if I say we're somewhat tired of those problems. Rosetta > has allowed people to fork upstream translations when we should only > have changed Ubuntu-specific strings. This leads to a terrible mess > where small teams have to manage a dramatically large textual domain > that they can't really master. Upstream translators work far better than > we can do on their projects, and avoid the kind of trouble we're now > facing: downstream-modified strings that don't get fixed when upstream > updates them. We really need a solution here, like locking translations > for packages that belong to upstream. Wouldn't have helped in this case. The buggy translations came from upstream. I agree that in some cases some locking would be useful. But on the other hand, if upstream translations have problems, they can be fixed faster for our users by using Launchpad (especially for stable releases, which don't receive upstream updates anymore except for regression and security fixes). > I'm sorry if this complaint sounds rude, but the tone of your message > and your way of presenting things isn't fair either. We're mostly > benevolent people here, and we suffer all the time from Launchpad's > framwerok problems I've just described. We're not here only to
Re: ubuntu-docs stats , xml and html
Hi Matthew, În data de Sb, 17-01-2009 la 11:02 +, Matthew East a scris: > Hi Adi, > > On Sun, Jan 11, 2009 at 4:28 AM, Adi Roiban wrote: > > I have also generated the HTML files for ubuntu-docs statistic and are > > available at the following address: > > > > http://ubuntu-docs-stats.tla.ro/ubuntu-8.10/ > > This is coming along nicely. However, at the moment, the site showing > up rather too many errors which are not really errors. > > For example, in the XML column, it shows up as "bad" where there is no > translation for a particular template. That isn't really an error, > it's just better to flag it up as missing in the first column, and > ignore it for the purposes of the second and third columns. > > Secondly, build warnings such as > http://ubuntu-docs-stats.tla.ro/ubuntu-8.10/report_html/about-ubuntu/ast.txt > are not really errors: these are perfectly normal and shouldn't show > up as errors. In fact, it's not really helpful to have the third > column report errors at all, what matters isn't whether the html build > runs smoothly or not (the third column), but whether the xml is valid > or not (the second column). If the xml is valid, then we are good to > go. > > So the only errors that really count are where the validate.sh script > returns an error, such as this one: > http://ubuntu-docs-stats.tla.ro/ubuntu-8.10/report_xml/programming/el.txt > > Hope the above was clear, if not give me a shout and we can talk it through. > I have updated the report according to your suggestions. I'm happy to receive any other comments from your or from other people. If you think the status page is OK and useful I will try to add a similar page for kubuntu, xubuntu, edubuntu , etc and for the future try to keep the stats updated so that we can use them to improve Jaunty quality. Kindest regards, -- Adi Roiban -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: HEADS-UP! URGENT! Major problem with translations for Hardy and Intrepid.
2009/1/17 Milan Bouchet-Valat : > Hi ! > > Wouldn't you mind giving us more details about the situation you > describe and its causes? You're suddenly coming and telling us that > everything is going to collapse and that we need to solve this horrible > list of bugs ASAP, without even explaining anything about it. Hear hear -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: HEADS-UP! URGENT! Major problem with translations for Hardy and Intrepid.
GNOME Dia has been updated upstream. -- Og B. Maciel omac...@foresightlinux.org ogmac...@gnome.org ogmac...@ubuntu.com GPG Keys: D5CFC202 http://www.ogmaciel.com (en_US) http://blog.ogmaciel.com (pt_BR) -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: HEADS-UP! URGENT! Major problem with translations for Hardy and Intrepid.
Hi! I reviewed the Asturian (ast) translation. It isn't a wrong files! :O The asturian files translation are fine! Only the templates po_gnome-system-monitor-ast in Intrepid has errors by next point 1. But I found this bugs with the command msgfmt -c file.po 1.- In Firefox more entries has this output: _firefox-ast.po:28: duplicate message definition... _firefox-ast.po:23: ...this is the location of the first definition But... this isn't a error! :O By example: Google is Google. 2.- In asturian we have 2 plurals, if we have translated only 1 plural, when we download the template from Launchpad, the command say that exist a wrong plural, because Launchpad not include in the downloaded template the "msgstr[1] """, only include the translated msgstr[0]. I think is a Launchpad Bug :O Can you confirm this, please? Thanks a lot! Cheers! Marcos. -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
HEADS-UP! URGENT! Major problem with translations for Hardy and Intrepid.
Hi ! Wouldn't you mind giving us more details about the situation you describe and its causes? You're suddenly coming and telling us that everything is going to collapse and that we need to solve this horrible list of bugs ASAP, without even explaining anything about it. >From what I've read and seen in the strings list, we're not in such an emergency. Sure, some strings are not correct and can lead to crashes if % jokers are present when they shouldn't. But this seems to have been the case since the release of Hardy and Intrepid, so no need to stress the teams like that. I really can't see your case here: what's new in Hardy and Intrepid that can break anything? Where does those new strings come from, and why can't they be reverted? Anyway, I think I'd express quite accurately the feeling of many l10n teams members if I say we're somewhat tired of those problems. Rosetta has allowed people to fork upstream translations when we should only have changed Ubuntu-specific strings. This leads to a terrible mess where small teams have to manage a dramatically large textual domain that they can't really master. Upstream translators work far better than we can do on their projects, and avoid the kind of trouble we're now facing: downstream-modified strings that don't get fixed when upstream updates them. We really need a solution here, like locking translations for packages that belong to upstream. I'm sorry if this complaint sounds rude, but the tone of your message and your way of presenting things isn't fair either. We're mostly benevolent people here, and we suffer all the time from Launchpad's framwerok problems I've just described. We're not here only to obey Canonical, and I think we deserve more than orders like "please report back". I appreciate your work on Ubuntu l10n, but please also understand ours. We need to understand what can be done in the future to avoid this kind of mess rather than blindly fixing things, waiting for new bugs to arise. I hope this can clarify things, and explain the problems we'll be facing when trying to improve things. -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Update: translation errors with msgids and msgstrs
Le Friday 16 January 2009 18:26:18 Arne Goetje, vous avez écrit : > Dear translators, > > for your convenience, here is the list of affected msgids, sorted by > release and language code: > > http://people.ubuntu.com/~arne/langpack_errors/ Thanks a lot, it's much easier to track errors this way. But all of those errors comes from usptream translations. This had to be fix by upstream teams first. We (French Ubuntu translators)are only work on Ubuntu specific apps and docs. For obvious reasons we don't want that Rosetta becomes a fork of upstream translations. Anyway, I've fixed many errors for Hardy in Rosetta. Most of them concern KDE 3.5 apps which are no more maintained by the KDE French team. > Please note, that these lists may contain false positives. Indeed, there's many false positives. It seems that an error occurs for each % character in translated strings! Here's an example : rosetta-hardy/fr/LC_MESSAGES/kttsd.po.c-format:1877: number of format specifications in 'msgid' and 'msgstr' does not match msgid "" "Sets the tone (frequency) of speech. Slide the slider to the left to lower " "the voice tone; to the right to increase tone. Anything less than 75 " "percent is considered \"low\", and anything greater than 125 percent is " "considered \"high\". You cannot change the pitch of MultiSyn voices." msgstr "" "Définit le ton (fréquence) de la prononciation. Faites défiler le curseur " "vers la gauche pour baisser le ton de la voix ; et vers la droite pour " "l'augmenter. Tout nombre inférieur à 75 % est considéré comme « faible », et " "tout nombre supérieur à 125 % est considéré comme « haut ». Vous ne pouvez " "pas modifier la fréquence de voix MultiSyn." Here the translator choose to use % instead of "percent", which is perfectly legitimate. Is this really a blocking issue for generating language packs ? Do you have any example of an application crach due to this kind of mistake in his translation ? -- Bruno -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Update: translation errors with msgids and msgstrs
fre 2009-01-16 klockan 23:07 +0100 skrev Ricardo Pérez López: > > http://people.ubuntu.com/~arne/langpack_errors/ > > Fixed for Spanish (es). > > By the way... why do the es_ES language exists? We (in Spain) always use > the es language (not the es_ES one). Swedish (sv) has now been taken cared of too. You should file a bug report for all packages that uses a es_ES translation. We have the same problem with sv_SE. Normally only locales such as zh_TW, zh_CN, pt_BR should use country-based translations. See http://www.debian.org/international/l10n/po/es_ES Daniel -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: ubuntu-docs stats , xml and html
Hi Adi, On Sun, Jan 11, 2009 at 4:28 AM, Adi Roiban wrote: > I have also generated the HTML files for ubuntu-docs statistic and are > available at the following address: > > http://ubuntu-docs-stats.tla.ro/ubuntu-8.10/ This is coming along nicely. However, at the moment, the site showing up rather too many errors which are not really errors. For example, in the XML column, it shows up as "bad" where there is no translation for a particular template. That isn't really an error, it's just better to flag it up as missing in the first column, and ignore it for the purposes of the second and third columns. Secondly, build warnings such as http://ubuntu-docs-stats.tla.ro/ubuntu-8.10/report_html/about-ubuntu/ast.txt are not really errors: these are perfectly normal and shouldn't show up as errors. In fact, it's not really helpful to have the third column report errors at all, what matters isn't whether the html build runs smoothly or not (the third column), but whether the xml is valid or not (the second column). If the xml is valid, then we are good to go. So the only errors that really count are where the validate.sh script returns an error, such as this one: http://ubuntu-docs-stats.tla.ro/ubuntu-8.10/report_xml/programming/el.txt Hope the above was clear, if not give me a shout and we can talk it through. -- Matthew East http://www.mdke.org gnupg pub 1024D/0E6B06FF -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
