View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003990 | Scribus | Translation | public | 2006-07-06 22:52 | 2009-02-12 20:04 |
Reporter | mhanski | Assigned To | malex | ||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | closed | Resolution | fixed | ||
Platform | Pentium(R) M processor 1.50GHz | OS | Kubuntu | OS Version | Dapper Drake |
Product Version | 1.2 | ||||
Fixed in Version | 1.3.3.13svn | ||||
Summary | 0003990: Please contact Rosetta admins and clarify the issue with their 1.2.* translations | ||||
Description | As stated above. Scribus has been neither officially listed in Rosetta as a "translatable application": https://launchpad.net/rosetta nor has the Scribus team been contacted and asked for permission, as required by Rosetta's New Import Policy: https://help.launchpad.net/RosettaNewImportPolicy But, there obviously is some activity going on (not much yet): https://launchpad.net/distros/ubuntu/dapper/+source/scribus/+translations This issue needs to be clarified by Scribus team with Rosetta admins: rosetta@launchpad.net | ||||
Tags | No tags attached. | ||||
Patch | |||||
|
Progress: Emailed rosetta admins a long letter discussing the situation. |
|
It looks like scribus got imported into Rosetat automatically as a part of their "complete istribution translation" effort. When told that .po files were no longer supported an of our own translation efforts the Rosetta people said that they would remove it. If we ever wanted to have Scribus as an official translation project in the Rosetta we'd have to first petition Ubuntu for support of the .ts format and then request the addition. |
|
thx malex. Please let us leave this bug open until the Rosetta people have really done it -- meaning removing the dapper and _edgy_ templates: https://launchpad.net/distros/ubuntu/edgy/+source/scribus/+pots/scribus |
|
Rosetta is an online web-based translation system. Often the people doing the translations are not developers and the system is design to making translation easy (and hopefully satisfying) for less developer-ish contributors. Before an Ubuntu release this is an effort by the translation team to translate as many of the applications in an K/Ubuntu release as possible and these are made available through the language-packs. Could somebody explain the issue beyond needing to get 'Scribus' removed from Rosetta. Is it because there are translations already done by the Scribus team that should be used in preference. If Scribus use a format other than .po files, I can potentially see an issue with sending translations "back upstream" to Scribus. Is there a converter between .po files and the .ts files, or some documentation or example on what a .ts files is? |
|
TS is a Qt based format that we prefer over PO. Most of our translators are not at all developers, and many of them are press related people and hence have the best knowledge of press based translation terms. Our files should be used over and above any other source of translation for this reason. Aside from that Rosetta only has Scribus 1.2.4.1, which we do not support anymore. If we were to support 1.2.x, it would be 1.2.5. We have stabilised 1.3.x via the 1.3.3.x series as 1.2.x is too old to support and 1.3.x has too many new features that people want. |
|
"Could somebody explain the issue beyond needing to get 'Scribus' removed from Rosetta. Is it because there are translations already done by the Scribus team that should be used in preference." Paul, I'd like to explain it a little more from a Scribus translator's point of view. We've established over the last years a pretty good workflow for our translators: we stay in touch with each other and the Scribus team, we upload our translations to this bug tracker, we are all Scribus mailing list subscribers. We were informed (accidentally) by one of Rosettas "official" Scribus translators that there are a couple of other guys doing Scribus translations, without the knowledge of the Scribus team and thus against Rosetta's own https://help.launchpad.net/RosettaNewImportPolicy Now if we look closer at the Scribus template in Rosetta, we will see, that e.g. English (Australia) 0 000.00 100.0% new, 2006-07-13 Chris Goerner English (United Kingdom) 0 000.00 100.0% new, 2006-10-20 Jeff Bailes which means that English (Australian) and English (UK) translations have been 100% translated in Rosetta by these two guys, Chris Goerner and Jeff Bailes. Now , this is more than funny from my point of view, since the English (UK) translations have been made _always_ to 100% by cbradney here, who is a core team dev, English translator and an Australian at that: http://docs.scribus.net/index.php?lang=en&page=transstats The same applies to Polish translations which happen to be my cup of tea, and which were delivered 100% with the 1.2.x series, but not in Rosetta, where 2085 are untranslated and a guy of whom we'd never heard obviosly has started to do something. I hope this clarifies a little, why we consider it somewhat disturbing. |
|
Thank you for the excellent guidance. With that starting point I've looked around and found out that the '.ts' Translation Source format is XML-based and very simple to parse; the result being similar to '.po', basically "original-string"<->"new-string". I've filed a bug report for Rosetta to support the '.ts' format for translations: https://launchpad.net/bugs/68959 In answer to the question about why 1.2.4 is in Rosetta; Rosetta has the *version(s)* of a program that have been shipped in an K/Ubuntu release. Scribus 1.2.4 shipped in Ubuntu 6.10 (release 2 days ago). The version of Scribus in the Ubuntu archive dependent on the version that was available in Debian unstable when Ubuntu was frozen (3 months before the Ubuntu release). Translations in Ubuntu are split-off into language-packs which continue to be updated and downloaded even after release. To allow any enthusiastic translators to continue working on updates for Ubuntu 6.06 and Ubuntu 6.10, those templates will need to continue to stay inside Rosetta so that the updated language-packs can be generated. As of this moment (2006-10-29), 'scribus_1.2.5.dfsg-3' is currently available in Debian, so you can be sure that version 1.2.5 or higher will be used in the next Ubuntu release in 6months time: http://packages.debian.org/cgi-bin/search_packages.pl?keywords=scribus&searchon=names&version=unstable The guidelines make note that they have been written in response to the existing system already in place. In the middle of the guidelines there is a talk about how programs are translated in three different ways depending on the choice of the upstream: * Upstream uses Rosetta directly as primary translation system. * Upstream's translation are import into Rosetta as a starting-point; updates by translators are only made available to the K/Ubuntu language-packs and not sent back upstream. * Upstream is GNOME or KDE with established in-house established translation infrastructure. Rosetta translations are offered as 'suggestions'. I believe Scribus is currently the second setup; where based on the work you've already done at the point of release, additional or missing translations can be filled in by translators using Rosetta and added to the language-packs, both before, and after an Ubuntu release. One thing I am curious about; in the source code, the: scribus/po/ directory contains a mixture of '.po' and '.ts' files; how does Qt/Scribus decided which to load? In response to the two examples of pl_PL and en_GB, in the Scribus 1.2.4 source code, these are both in '.ts' format so likely will not have been picked up. Whereas the French, 'pt_BR' and Slovak translations are in '.po' format and how as 100% in Rosetta: https://launchpad.net/distros/ubuntu/edgy/+source/scribus/+pots/scribus It sounds like just teaching Rosetta and the language pack build system about '.ts' files should deal with the duplication issue completely! |
|
Actually it's probably been more then 3 months since I uploaded Scribus 1.2.5 into Debian on July 19th - "[2006-07-19] Accepted 1.2.5.dfsg-1 from http://packages.qa.debian.org/s/scribus.html. Per sladen's suggestions - if Ubuntu/Rosetta added .ts format to their supported translation formats and used our upstream translations as authoritative at all times via regular merges where upstream translated strings override Rosetta changes then there would be much less contention about this issue. |
|
malex: Double-checking the release timetable: https://wiki.ubuntu.com/EdgyReleaseSchedule The Ubuntu archive hit UpstreamVersionFreeze on 2006-07-13, which is the point when automatic syncs from Debian stop and the Ubuntu teams start bug-fixing furiously. The 1.2.5 upload just missed getting synced into edgy by ~1week. malex: Yes, if the translations are there in the source code (and .ts _recognised_ as being such ;-) they'll get used. Nobody would attempt to duplicate work unnecessaryily! |
|
Please understand that we really do not plan to support 1.2.x anymore. We have done a lot of work to stabilised our development 1.3.x series in a mini 1.3.3.x series while we continue work on 1.3.4 and above. Too many people wanted the new features and therefore it made sense to stabilise that version. Also, 1.3.3.5 will be released within the next week, and contains a more translations, including the mentioned Australian. I'm, not sure how your process handles when upstream releases a new version? Are all those rosetta based translations lost or can they be brought forward without replacing new and updated ones in the new versions? How can you feedback new files to us without any (perceived) relationship. We would be very glad to include them. Also, note that our french team moved from PO to TS to more correctly handle contexts and context comments. |
|
Ah yes, I think the Scribus team moving onto 1.3.* is appreciated. The *Ubuntu* will of course attempt to continue support for 1.2.4 over the next 18months as part of K/Ubuntu 6.10 and 30months as part of K/Ubuntu 6.06LTS (the Long Term Support release). Ubuntu attempts to stay as close to Debian as possible, to reduce the delta between the distributions. Around 90% of software in the Ubuntu archive is identical at the Source level to the version in the Debian archive. The Ubuntu team will ship (exceptions excepted) with whatever versions are available in Debian unstable, at the point of the Upstream Version Freeze (UVF) date. If Scribus 1.3.4 can be got into Debian by then (December/January), the latest and greatest Scribus will be shipped! The Ubuntu team would certainly appreciate advice about what version of Scribus you believe should ship. cbradney: Rosetta will merge identical translated strings across different versions of software. One of the options in Rosetta is "Download as .po", hopefully in the future there will be a "Download as .ts" option aswell. I guess when there are '.po' and '.ts' the timestamps will need checking to see which is the most recently updated. Interesting, some investigation needs doing into how exactly the Qt Translation Services pick '.qm' verses '.mo' compiled versions of translations. |
|
As a note, qm is the compressed binary version of the translations, we use the Qt tools to convert the .ts into a qm. We could in theory only include the qm files in the binary package. As for packaging, Scribus is a case where you *absolutely* should break any and all rules to put 1.3.3.6+ into your distro and drop 1.2x. I was the last developer to support maintaining that release and I no longer will. In the FAQ and when Ubuntu users visit IRC for support they are first told to upgrade to scribus-ng from our repository, before we offer any assitance. |
|
After all this talking I see Scribus again as translatable application in Gutsy and people translating it without contacting official translators. https://translations.launchpad.net/ubuntu/gutsy/+source/scribus/+pots/scribus This is getting ridiculous. Is there a tiny chance we could have this sorted out now and forever, please? |
|
Seems fixed now, at least for the 1.3.3.x series |
|
Neither intrepid nor jaunty appear to have scribus translation pages. |
Date Modified | Username | Field | Change |
---|---|---|---|
2006-07-06 22:52 | mhanski | New Issue | |
2006-07-06 22:53 | mhanski | Description Updated | |
2006-07-19 21:53 | cbradney | Status | new => assigned |
2006-07-19 21:53 | cbradney | Assigned To | => malex |
2006-08-15 13:44 |
|
Severity | major => minor |
2006-10-17 21:39 | mhanski | Relationship added | related to 0004423 |
2006-10-18 00:48 | malex | Note Added: 0013017 | |
2006-10-23 05:59 | malex | Note Added: 0013104 | |
2006-10-23 06:46 | mhanski | Note Added: 0013105 | |
2006-10-23 07:29 | mhanski | Note Edited: 0013105 | |
2006-10-23 09:25 | mhanski | Note Edited: 0013105 | |
2006-10-28 20:28 | sladen | Note Added: 0013153 | |
2006-10-28 20:34 | cbradney | Note Added: 0013154 | |
2006-10-28 22:21 | mhanski | Note Added: 0013159 | |
2006-10-28 22:28 | mhanski | Note Edited: 0013159 | |
2006-10-28 22:30 | mhanski | Note Edited: 0013159 | |
2006-10-29 01:02 | sladen | Note Added: 0013160 | |
2006-10-29 02:23 | malex | Note Added: 0013161 | |
2006-10-29 02:59 | sladen | Note Added: 0013163 | |
2006-10-29 08:27 | cbradney | Note Added: 0013164 | |
2006-10-29 12:59 | sladen | Note Added: 0013171 | |
2007-01-11 21:54 |
|
Note Added: 0014748 | |
2007-07-20 23:38 | alexandre | Note Added: 0016840 | |
2008-01-17 21:13 | deejay1 | Note Added: 0018629 | |
2009-02-12 20:04 | malex | Note Added: 0021117 | |
2009-02-12 20:04 | malex | Status | assigned => closed |
2009-02-12 20:04 | malex | Resolution | open => fixed |
2009-02-12 20:04 | malex | Fixed in Version | => 1.3.3.13svn |