Re: Rosetta-Feedback - UDS Prague
Am Donnerstag, den 26.06.2008, 21:31 +0200 schrieb Milo Casagrande: > Il giorno mer, 18/06/2008 alle 12.30 +0200, Danilo Šegan ha scritto: > > Mark also had a nice idea of having a review-template (containing > > common terms, constructions, and problematic cases). Reviewers > > would point people at it, prospective translators would provide their > > translations, and reviewers could easily evaluate their translation > > abilities. If only somebody would spend time preparing such a POT file :) > > That's an interesting idea Danilo... I could try to find some time and > take a look at how to do it during the coming summer... > > But why not having a small application like "Hello World!" for > "developers", a "Hello Translator!" (with a small doc too maybe) with > which wannabe translators can train? So to have different casistics: > tooltips, menus, buttons, radio-bottons, plural forms... Danilo, how could we reset the translation and the suggestions in Rosetta? One of our translators would also like to work on this. I just registered a project called translation-school and the corresponding team translation-school-hackers. The source code repository contains skeletons for a python application, documentation and text examples. Each one will use its own po template. Furthermore an update-po and create-tarball script are included. It should not be very hard to add a small GTK user interface for the example application and get it shipped in Universe. So a new translator could easily run the application on his or her system and browse the documentation. Cheers, Sebastian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
Il giorno mer, 18/06/2008 alle 12.30 +0200, Danilo Šegan ha scritto: > Mark also had a nice idea of having a review-template (containing > common terms, constructions, and problematic cases). Reviewers > would point people at it, prospective translators would provide their > translations, and reviewers could easily evaluate their translation > abilities. If only somebody would spend time preparing such a POT file :) That's an interesting idea Danilo... I could try to find some time and take a look at how to do it during the coming summer... But why not having a small application like "Hello World!" for "developers", a "Hello Translator!" (with a small doc too maybe) with which wannabe translators can train? So to have different casistics: tooltips, menus, buttons, radio-bottons, plural forms... -- Milo Casagrande <[EMAIL PROTECTED]> signature.asc Description: Questa è una parte del messaggio firmata digitalmente -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
Weytk-p, I've started a new wiki page TranslatingUbuntu/NewLanguages. It's bare bones and probably full of grammatical errors, but It captures the essence of where I want to go with this page. I'm by no means an expert on all these subsystems and components so please correct me if I'm wrong. For most of my work to improve the support for Secwepemctsin I have been submitting it upstream first and then creating a bug in launchpad after it has been accepted upstream. Sometimes a package will have the new version with my work and sometimes so they have to patch an older version. Would that be a ood workflow to follow? There are many issues with indigenous peoples and localization. There are many problems on top of the ones Timo mentioned. Some are: different calendars, regional spelling differences within countries, different orthographies. It's a lot of work to do this, but it's well worth doing if it preserves the linguistic diversity for future generations. -Neskie [1] - https://wiki.ubuntu.com/TranslatingUbuntu/NewLanguages -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
2008/6/18 Danilo Šegan <[EMAIL PROTECTED]>: > Hi Kenneth, > > Today at 12:56, Kenneth Nielsen wrote: > > >> I think you are missing one important point. A "reviewer" can also > >> submit translations without waiting for them to be reviewed. > > > > No > > Sorry, but yes :) Whether that's desired is a different topic. Yeah ok :) That was what I meant. > > > > I.e. by reviewing someone's translations, you are aiming for a new > >> 'trusted' translator as well. > > > > Not if we can't provide feedback and make them make the corrections > > themselves. > > I already acknowledged that we are missing commenting feature and that > it's important for reviewer's work. > I also mentioned how external > communication is still essential for running a translation team in LP > (due to lack of such commenting feature). Yeah I know, sorry, I was just reiterating. > > > >> So, now it'll be two guys who can > >> translate directly, and if that doesn't speed you up long-term, I > >> don't know what will. > > > > I think you are missing an important point here. There are _many_ > upstream > > translators/translation teams that consider reviewing translations, even > > those done by seasoned translators, as a integral part of the translation > > Actually, I am quite aware of that. And I am doing some improvements to > enable reviewers to submit only suggestions (which is what they can't > do right now). > > > process, that is absolutely necessary to reach a high quality output. > E.g. > > _all_ translations submitted to the GNOME SVN for the Danish language has > > been reviewed, indenpendently of the translator. We don't want to > comprimise > > our standards for quality in Ubuntu, hence what we need is a way to > quickly > > review, _not_ "correct", a translation, because if we correct them > ourselves > > then translator will not learn anything and the reviewers will have to > keep > > correcting the same things. > > You do make a strong case here. I am thinking out loud, but if we > modify the translator evaluation page to group submissions by > dates, I think we'd have a good enough approximation to your 'point > diff' approach. Yes good idea. Maybe, make it an option. The mechanism to comment on such sets of suggestions would be very > useful, indeed, but I think intially just having them per single page > which you could copy and paste into email should be a big help. Yes definitely. Having the new_suggestions_per_person_per_module-page you mentioned in your previous e-mail would be A alpha 1 numore uno. Later having commenting features on that page would make it complete. > > > > What we do when we review is to read through the translations, commenting > > only on the one that needs commenting, and only in as much detail as is > > required for the individual string. This can sometimes only be a single > word > > or sentence "Typo", "Reformulate to avoid english sentence structure", > > "misgid has plural" or sometimes it can be a long explanation of some > > preferred terminology or policy. This all means that I can review and > > provide feedback for translations, as fast as I can read, write and > delete > > text in a text editor and send an email, and _that_ is what I am looking > > for. My suggested "point-diff" approach will allow for that, in parallel > > with anything else you guys might think up as the main approach in the > > web-interface. > > Actually, I am sorry to say that I haven't heard a single comment > about the existing evaluation view. That is too bad. The ideas from this thread can > make it much more useful, and I'd be happy to spend some more time > thinking about this, and later working on it. Yeah. I'm sorry I don't have time to do it myself, but if you do put this down in a development specification, would you then mind dropping the link here, possibly along with other dev.specs. pertaining to the issues we have discussed here. Then I will subscribe to them and possibly getting feedback on them. However, don't put up your hopes too high: it will take a while until > I find time to work on this, especially now that it's just Jeroen and > me working on LP Translations. Ok, sure. > If anyone feels like working on Launchpad Translations, check out > > http://webapps.ubuntu.com/employment/canonical_LTSE/ Well linking to what I wrote earlier, I espect to finish my masters in applied physics mid august, so I don't think I will apply ;) Regards Kenneth Nielsen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
Hi Kenneth, Today at 12:56, Kenneth Nielsen wrote: >> I think you are missing one important point. A "reviewer" can also >> submit translations without waiting for them to be reviewed. > > No Sorry, but yes :) Whether that's desired is a different topic. > I.e. by reviewing someone's translations, you are aiming for a new >> 'trusted' translator as well. > > Not if we can't provide feedback and make them make the corrections > themselves. I already acknowledged that we are missing commenting feature and that it's important for reviewer's work. I also mentioned how external communication is still essential for running a translation team in LP (due to lack of such commenting feature). >> So, now it'll be two guys who can >> translate directly, and if that doesn't speed you up long-term, I >> don't know what will. > > I think you are missing an important point here. There are _many_ upstream > translators/translation teams that consider reviewing translations, even > those done by seasoned translators, as a integral part of the translation Actually, I am quite aware of that. And I am doing some improvements to enable reviewers to submit only suggestions (which is what they can't do right now). > process, that is absolutely necessary to reach a high quality output. E.g. > _all_ translations submitted to the GNOME SVN for the Danish language has > been reviewed, indenpendently of the translator. We don't want to comprimise > our standards for quality in Ubuntu, hence what we need is a way to quickly > review, _not_ "correct", a translation, because if we correct them ourselves > then translator will not learn anything and the reviewers will have to keep > correcting the same things. You do make a strong case here. I am thinking out loud, but if we modify the translator evaluation page to group submissions by dates, I think we'd have a good enough approximation to your 'point diff' approach. The mechanism to comment on such sets of suggestions would be very useful, indeed, but I think intially just having them per single page which you could copy and paste into email should be a big help. > What we do when we review is to read through the translations, commenting > only on the one that needs commenting, and only in as much detail as is > required for the individual string. This can sometimes only be a single word > or sentence "Typo", "Reformulate to avoid english sentence structure", > "misgid has plural" or sometimes it can be a long explanation of some > preferred terminology or policy. This all means that I can review and > provide feedback for translations, as fast as I can read, write and delete > text in a text editor and send an email, and _that_ is what I am looking > for. My suggested "point-diff" approach will allow for that, in parallel > with anything else you guys might think up as the main approach in the > web-interface. Actually, I am sorry to say that I haven't heard a single comment about the existing evaluation view. The ideas from this thread can make it much more useful, and I'd be happy to spend some more time thinking about this, and later working on it. However, don't put up your hopes too high: it will take a while until I find time to work on this, especially now that it's just Jeroen and me working on LP Translations. If anyone feels like working on Launchpad Translations, check out http://webapps.ubuntu.com/employment/canonical_LTSE/ :) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
2008/6/18 Danilo Šegan <[EMAIL PROTECTED]>: > Hi Kenneth, > > On Saturday at 15:47, Kenneth Nielsen wrote: > > > It sounds like you guys had a very good discussion and I can > whole-heartedly > > sign off on all of your points. Especially I think that you with 1, 2 and > 3 > > have essentially captured the essence of my last nerveous breakdown ;) > > > > There is one point that I would like to elaborate on and that has to do > with > > reviewing and QA. I think that right now there are a lot of suggestions > for > > how to improve the LP UI to make this better and easier and that's fine, > but > > I think you have to consider making a policy change considering LP that > > allows people to take part of this job outside of LP as an option. The > > problem is that the people that currently work as admins and reviewers > are > > "old" guys who has previously worked with upstream projects, and for > them/us > > the LP way looks like a lot of unnecessary mouse clicks and wasted time. > > Upstream, say in GNOME, you might have a process like this: > > * A translator sends a diff-file that represents his latest translations > > contributions to a list for review > > * The reviewer opens the diff in his favorite text editor, say emacs, > > comment on the strings that need commenting and delete the rest, send > that > > back to the transator > > * If the translator agress with the comments he makes the changes and > sends > > the finished file for integration --- > > * which is accomplished by a couple of svn commands by the admin > > > > So all in all, a couple of emails and some pure text editing and it's > done. > > You make it sound like it's a few minutes of work, when it's anything > but. :) Yeah I know :) But that is also the reason why it is important a) to make sure that the workprocess is stripped of anything that will make in in effective and b) that it is possible for you to make as sure as you can that your work will not go to waste. I'll return to this, becasue that is actually one of my points > > > The only capability we lack at the moment is making comments for > rejected/modified suggestions. All the other steps are possible, and > actually easier with Launchpad. Ahh well, I guess that depends of what tools people prefer. If it will require me to mouse-click the "return with comment" button in order to have the text field appear where I can write the comment I still _prefer_ the old way. BUT that is purely a matter of me being old :) and I could defenitily get used to working with a multiple mouse-clicky web-interface once we get these few more features in ;) > > Considering this, any review process that require one mouse click per > > string, and possible waiting for a page to load for every 10 strings you > > want to review and has no "built-in"/easy posibility for feedback, is > just > > to much trouble . > > > I agree 10-strings-per-page is too low for serious review work. > However, knowing that you are not a newbie, I'd be surprised if you > haven't found a way to enlarge that number :) Yes I have. But surely you agree that I shouldn't have to do it like that. I believe an LP a settings page, where I can choose to always have 50 strings shown at a time when I'm doing reviewing or even translating, somewhere on my personal LP page would be in order. You (or the usability guys) can bury these options as deep in the GUI as you want to not mess with the simplicity, as long as it is there to find if you know where to look > However, I find that one click is hardly a limitation. Ahh well. One click and 5-10 seconds of waiting for the page to load for every 10 strings for review, GNOME e.g. has ~35000-4 strings and ~10-15% replacement or addition every 6 months, I'm sure you can do the math. (I know that it would also take time to load a big page, but that will be 1 much bigger chunk of time in stead of many small. The bigger wait I can use for something else, I can't do that with the many small) > > > (Btw, I'd leave the decision to usability guys) > > > Therefore I think it would be very nice to have a process in LP that > mimics > > parts of this process simply because it is so easy, and I do have en idea > on > > how to accomplish this. I involves two different expansions/modifications > to > > LP and therefore do include some work on the part of the developers, but > I > > think it would be worth it. I have written the idea out below, I was > > planning to put these in development specifications but I have been crazy > > busy the last 10 months with my masters thesis work (and will be so for > the > > next few months also). Suggestion 1 is only a tool needed for suggestions > 2. > > Thanks for taking the time to describe this here. > > > 1) Making it possible to "sign of" on a translation suggestion > > Description: This would be an option to say that you think that an > already > > existing suggestion is good, and that you would have made the same > > suggestion if it was
Re: Rosetta-Feedback - UDS Prague
Kennet Nielsen wrote: "I think you are missing an important point here. There are _many_ upstream translators/translation teams that consider reviewing translations, even those done by seasoned translators, as a integral part of the translation process, that is absolutely necessary to reach a high quality output. E.g. _all_ translations submitted to the GNOME SVN for the Danish language has been reviewed, indenpendently of the translator. We don't want to comprimise our standards for quality in Ubuntu, hence what we need is a way to quickly review, _not_ "correct", a translation, because if we correct them ourselves then translator will not learn anything and the reviewers will have to keep correcting the same things." What about Rosetta sending an email to last translation indicating the correction then? Just an (obvious) idea. -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
Hi Kenneth, On Saturday at 15:47, Kenneth Nielsen wrote: > It sounds like you guys had a very good discussion and I can whole-heartedly > sign off on all of your points. Especially I think that you with 1, 2 and 3 > have essentially captured the essence of my last nerveous breakdown ;) > > There is one point that I would like to elaborate on and that has to do with > reviewing and QA. I think that right now there are a lot of suggestions for > how to improve the LP UI to make this better and easier and that's fine, but > I think you have to consider making a policy change considering LP that > allows people to take part of this job outside of LP as an option. The > problem is that the people that currently work as admins and reviewers are > "old" guys who has previously worked with upstream projects, and for them/us > the LP way looks like a lot of unnecessary mouse clicks and wasted time. > Upstream, say in GNOME, you might have a process like this: > * A translator sends a diff-file that represents his latest translations > contributions to a list for review > * The reviewer opens the diff in his favorite text editor, say emacs, > comment on the strings that need commenting and delete the rest, send that > back to the transator > * If the translator agress with the comments he makes the changes and sends > the finished file for integration --- > * which is accomplished by a couple of svn commands by the admin > > So all in all, a couple of emails and some pure text editing and it's done. You make it sound like it's a few minutes of work, when it's anything but. :) The only capability we lack at the moment is making comments for rejected/modified suggestions. All the other steps are possible, and actually easier with Launchpad. > Considering this, any review process that require one mouse click per > string, and possible waiting for a page to load for every 10 strings you > want to review and has no "built-in"/easy posibility for feedback, is just > to much trouble . I agree 10-strings-per-page is too low for serious review work. However, knowing that you are not a newbie, I'd be surprised if you haven't found a way to enlarge that number :) However, I find that one click is hardly a limitation. (Btw, I'd leave the decision to usability guys) > Therefore I think it would be very nice to have a process in LP that mimics > parts of this process simply because it is so easy, and I do have en idea on > how to accomplish this. I involves two different expansions/modifications to > LP and therefore do include some work on the part of the developers, but I > think it would be worth it. I have written the idea out below, I was > planning to put these in development specifications but I have been crazy > busy the last 10 months with my masters thesis work (and will be so for the > next few months also). Suggestion 1 is only a tool needed for suggestions 2. Thanks for taking the time to describe this here. > 1) Making it possible to "sign of" on a translation suggestion > Description: This would be an option to say that you think that an already > existing suggestion is good, and that you would have made the same > suggestion if it wasn't already there. That's what you do by approving a suggestion. > Implementation considerations: UI-wise this would require a little button > next to the suggestions and a link in the string that contains the source of > the suggestions, where you could see the people that have signed of on the > suggestion. I think this represents very little of "UI-cluttering" that > Danilo mentions that he would like to avoid. So, you want to have several people 'signing off' on a suggestion? What I wonder is will that be used at all, and if it will, will it be used on more than 1% of strings. My suspicion is that no, it will not be used on more than 1% of strings, meaning that 99% of messages will have UI more cluttered (our UI is already too complex imho). This is basically 'voting' per message, and I think that's simply too much. > 2) Making it possible to store a set of suggestions and approve/implement > such a list with one action > Description: After going through a translations and making as many > suggestions or signing of on others ^^ it should be possible to save a list > of all the suggestions _you_ made or signed off on as some sort of an object > (lets call it a point-diff) and give it a name. It should then be possible > to see a list of such point-diffs, to export them as a old style diff and to > approve/(implement the changes the describe) them with just one action as an > admin and possible to proofread them and provide text feedback on a > point-diff basis directly in LP. This sounds like a cool idea, but also sounds pretty hard with our current DB model (i.e. this is a big architectural change, basically, svn vs. cvs style: in SVN one revision holds all changes from a single commit, in CVS each file has their own revision numbers and it's hard to find what w
Re: Rosetta-Feedback - UDS Prague
2008/6/18 Danilo Šegan <[EMAIL PROTECTED]>: > Hi Kenneth, > > On Saturday at 16:04, Kenneth Nielsen wrote: > > >> > Furthermore it is also very time consuming to review and approve > >> > suggestions. I don't see a real speedup compared to writing them on my > >> > own. Especially since there is no way to provide feedback to the > >> > translators in Rosetta. If there is no contact outside of Rosetta I > have > >> > to correct the same errors again and again. > >> > >> I believe the lack of documentation is to blame here. Reviewing > >> suggestions would not speed you up short-term, but once you have > >> reviewed enough of someone's translations and start considering him a > >> good translator, you'd make him a reviewer as well, and then it would > >> be two of you translating, and two of you reviewing. > > > > > > I disagree. I believe it is the process currently involved that is the > > principal source of the time used reviewing, reviewing _can_ be done in a > > manner that takes less time per string than you would use translating it > > your self, so getting more people to review would simply mean more people > > wasting time. > > I think you are missing one important point. A "reviewer" can also > submit translations without waiting for them to be reviewed. No I.e. by reviewing someone's translations, you are aiming for a new > 'trusted' translator as well. Not if we can't provide feedback and make them make the corrections themselves. > So, now it'll be two guys who can > translate directly, and if that doesn't speed you up long-term, I > don't know what will. I think you are missing an important point here. There are _many_ upstream translators/translation teams that consider reviewing translations, even those done by seasoned translators, as a integral part of the translation process, that is absolutely necessary to reach a high quality output. E.g. _all_ translations submitted to the GNOME SVN for the Danish language has been reviewed, indenpendently of the translator. We don't want to comprimise our standards for quality in Ubuntu, hence what we need is a way to quickly review, _not_ "correct", a translation, because if we correct them ourselves then translator will not learn anything and the reviewers will have to keep correcting the same things. What we do when we review is to read through the translations, commenting only on the one that needs commenting, and only in as much detail as is required for the individual string. This can sometimes only be a single word or sentence "Typo", "Reformulate to avoid english sentence structure", "misgid has plural" or sometimes it can be a long explanation of some preferred terminology or policy. This all means that I can review and provide feedback for translations, as fast as I can read, write and delete text in a text editor and send an email, and _that_ is what I am looking for. My suggested "point-diff" approach will allow for that, in parallel with anything else you guys might think up as the main approach in the web-interface. Regards Kenneth Nielsen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
Hi Kenneth, On Saturday at 16:04, Kenneth Nielsen wrote: >> > Furthermore it is also very time consuming to review and approve >> > suggestions. I don't see a real speedup compared to writing them on my >> > own. Especially since there is no way to provide feedback to the >> > translators in Rosetta. If there is no contact outside of Rosetta I have >> > to correct the same errors again and again. >> >> I believe the lack of documentation is to blame here. Reviewing >> suggestions would not speed you up short-term, but once you have >> reviewed enough of someone's translations and start considering him a >> good translator, you'd make him a reviewer as well, and then it would >> be two of you translating, and two of you reviewing. > > > I disagree. I believe it is the process currently involved that is the > principal source of the time used reviewing, reviewing _can_ be done in a > manner that takes less time per string than you would use translating it > your self, so getting more people to review would simply mean more people > wasting time. I think you are missing one important point. A "reviewer" can also submit translations without waiting for them to be reviewed. I.e. by reviewing someone's translations, you are aiming for a new 'trusted' translator as well. So, now it'll be two guys who can translate directly, and if that doesn't speed you up long-term, I don't know what will. As Sebastian pointed out though, we need to improve the process, and improve the documentation. Mark also had a nice idea of having a review-template (containing common terms, constructions, and problematic cases). Reviewers would point people at it, prospective translators would provide their translations, and reviewers could easily evaluate their translation abilities. If only somebody would spend time preparing such a POT file :) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
2008/6/15 Neskie Manuel <[EMAIL PROTECTED]>: > I would like to work with somone, > interested on implementing features and writing/collecting > documentation that would make this easier for other new translation > teams. This would be helpful for groups in North America, Papua New > Guinea, South America, and other areas where people are starting > fresh. Since this is clearly something very close to Ubuntu philosophy in general, I'd hope someone at Canonical could spare some time helping in writing this kind of documentation together. But anyway since you seem to have quite a lot of knowledge already, it would be great to have at least something written down in page named eg. "Getting new language up and running HOWTO" in Ubuntu wiki https://wiki.ubuntu.com/TranslatingUbuntu or other place. I don't think there's a general guide anywhere that covers all of glibc locale information adding, keyboards, fonts, Unicode CLDR information and other stuff like that? Some statistics about Sami languages that are spoken around here in the Nordic countries, even though I don't speak any of them: out of the 9 still existing Sami languages, only the biggest one (Northern Sami, sme, 3 speakers) has the mentioned basic things covered and some KDE translations are actually in Ubuntu. Out of the rest, at least Southern Sami (sma_NO, ca. 500 speakers), Lule Sami (smj_SE, ca. 1500 speakers), Skolt Sami (sms_FI, ca. 400 speakers) and Inari Sami (smn_FI, ca. 300 speakers) could have IMO real possibilities of translating Ubuntu. For example Skolt Sami and Inari Sami have quite well preserved status here in Finland despite the low number of speakers. Kildin Sami spoken in Russia has apparently no approved language code even though it has ca. 650 speakers, because of orthographical issues + lots of dialects. One interesting topic is also how to decide the default country codes for the locales to be used - it's relatively clear when the largest proportion of speakers is in one country (like I chosed countries for the mentioned other Sami languages), but there might be quite corner cases. I think the default Northern Sami configuration had _NO assumed, even though there are thousands of speakers in Sweden and Finland, too. -Timo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
Weytk-p (Hello Everyone), I am the lead person on the Ubuntu Secwepemc Translators team. We are a completly new team coming from zero localization. This would be the same for any North American Indigenous Language [1] [2]. We don't have any problems with syncing with upstream since there is no upstream. The main problem all of these languages are facing before they can even use Rosetta is getting basic support. This includes: * ORTHOGRAPHIC Having the orthographic information as part of Fontconfig. I've been adding orthographic information to fontconfig with the aid of [2]. Gnome uses this to determine which languages are displayable. I dont know how KDE does it. Having this information allows teams to know which fonts they can use by typing fc-list :lang=ISO_CODE. * FONTS. Having a font that displays all of their characters currently in Debian and Ubuntu the only font that displays all of the various North American Indigenous Languages is the package ttf-lg-aboriginal. DejaVu has a subset for some but not all North American Orthographies. * KEYBOARDS. Once a font support is available, these languages need a way to input their language efficiently. I've written a Cherokee ( really cool story behind the script) xkb keyboard, a Secwepemctsin keyboard. There has been an Inuktitut xkb keyboard for some time now. Inuktitut covers one sort of syllabics, but there is also the need for a Blackfoot, Ojibway, Cree, and Naskapi syllabics as well. These are the languages with the largest amount of speakers in Canada. * COLLATION. Actually I don't really know anything about this but know you need it for the next major thing required * TIME. The names of the months and days and the first day of the week is need to create locales, in the case of North American Indigenous languages this could be retrieved from First Voices [3]. * LOCALE. There are currently no locales that have been created for and submitted to glibc for any North American Indigenous Languages except: Secwepemctsin (shs_CA). I have created locales for Naskapi (nsk_CA), Ktunaxa (kut_CA), Mi'kmaw (mic_CA), and Ojibwe (oji_CA). These are unverified as of yet, but should be fine. These are some of the things that I've had to learn as I start using Rosetta ands translating Ubuntu. Rosetta should reflect the fact that some people will be starting from a point of no localization and will have to implement the above items. I would like to work with somone, interested on implementing features and writing/collecting documentation that would make this easier for other new translation teams. This would be helpful for groups in North America, Papua New Guinea, South America, and other areas where people are starting fresh. Yeri Tsucws (That's All) -Neskie [1] - http://wiki.debian.org/I18n/NorthAmericanIndigenousLanguages [2] - http://www.languagegeek.com/alllangs/listoflangs.html [3] - http://firstvoices.ca -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
2008/6/13 Danilo Šegan <[EMAIL PROTECTED]>: > > As western Ubuntu translators we only have to translate a small subset > > of packages, basically the ones written under the Ubuntu umbrella, and > > the documentation. Furthermore we have to spot for import errors and > > keep an eye on single missing or changed strings. What we want to avoid > > is a brain split between upstream and Ubuntu translations. For this task > > we only need a team of about 5 to 10 active translators, who are capable > > and interested in polishing. > > Indeed, this is something where we need better sync with upstream > translations for it to be practical: i.e. as long as what you see in > Launchpad are the latest translations from upstream, I don't see any > problem with current Launchpad approach. Of course, some minor UI > improvements are to be done (like grouping packages into > ubuntu-desktop, kubuntu-desktop,...), and we are planning on doing > them, but it all takes time. Indeed. Regarding making e.g. ubuntu-desktop groupings, from my point of view, as a person the worries about Ubuntu-upstream contribution conflicts, it would be much more useful to have groupings based on the upstream locations of the package, say make a GNOME-group, KDE-group, XFCE-group, TP-group, LP-group and "Scattered upstream"-group. That would make it very much easier to explain to a newcomer what he should do to contribute to a speceific package depending on which group it is in. > > Furthermore it is also very time consuming to review and approve > > suggestions. I don't see a real speedup compared to writing them on my > > own. Especially since there is no way to provide feedback to the > > translators in Rosetta. If there is no contact outside of Rosetta I have > > to correct the same errors again and again. > > I believe the lack of documentation is to blame here. Reviewing > suggestions would not speed you up short-term, but once you have > reviewed enough of someone's translations and start considering him a > good translator, you'd make him a reviewer as well, and then it would > be two of you translating, and two of you reviewing. I disagree. I believe it is the process currently involved that is the principal source of the time used reviewing, reviewing _can_ be done in a manner that takes less time per string than you would use translating it your self, so getting more people to review would simply mean more people wasting time. > I.e. imagine sequence of uploads: > > Last-Translator: Sascha > msgid "File" msgstr "Datei" > > Last-Translator: Karl > msgid "File" msgstr "DDatei" > > Last-Translator: Karl > msgid "File" msgstr "Datei" > > This may lead to a case of translator Sascha and reviewer Karl. Ahh I see. Yeah that we need to doecument at some time. Regards Kenneth Nielsen -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Rosetta-Feedback - UDS Prague
Hallo Sebastian It sounds like you guys had a very good discussion and I can whole-heartedly sign off on all of your points. Especially I think that you with 1, 2 and 3 have essentially captured the essence of my last nerveous breakdown ;) There is one point that I would like to elaborate on and that has to do with reviewing and QA. I think that right now there are a lot of suggestions for how to improve the LP UI to make this better and easier and that's fine, but I think you have to consider making a policy change considering LP that allows people to take part of this job outside of LP as an option. The problem is that the people that currently work as admins and reviewers are "old" guys who has previously worked with upstream projects, and for them/us the LP way looks like a lot of unnecessary mouse clicks and wasted time. Upstream, say in GNOME, you might have a process like this: * A translator sends a diff-file that represents his latest translations contributions to a list for review * The reviewer opens the diff in his favorite text editor, say emacs, comment on the strings that need commenting and delete the rest, send that back to the transator * If the translator agress with the comments he makes the changes and sends the finished file for integration --- * which is accomplished by a couple of svn commands by the admin So all in all, a couple of emails and some pure text editing and it's done. Considering this, any review process that require one mouse click per string, and possible waiting for a page to load for every 10 strings you want to review and has no "built-in"/easy posibility for feedback, is just to much trouble . Therefore I think it would be very nice to have a process in LP that mimics parts of this process simply because it is so easy, and I do have en idea on how to accomplish this. I involves two different expansions/modifications to LP and therefore do include some work on the part of the developers, but I think it would be worth it. I have written the idea out below, I was planning to put these in development specifications but I have been crazy busy the last 10 months with my masters thesis work (and will be so for the next few months also). Suggestion 1 is only a tool needed for suggestions 2. 1) Making it possible to "sign of" on a translation suggestion Description: This would be an option to say that you think that an already existing suggestion is good, and that you would have made the same suggestion if it wasn't already there. Implementation considerations: UI-wise this would require a little button next to the suggestions and a link in the string that contains the source of the suggestions, where you could see the people that have signed of on the suggestion. I think this represents very little of "UI-cluttering" that Danilo mentions that he would like to avoid. 2) Making it possible to store a set of suggestions and approve/implement such a list with one action Description: After going through a translations and making as many suggestions or signing of on others ^^ it should be possible to save a list of all the suggestions _you_ made or signed off on as some sort of an object (lets call it a point-diff) and give it a name. It should then be possible to see a list of such point-diffs, to export them as a old style diff and to approve/(implement the changes the describe) them with just one action as an admin and possible to proofread them and provide text feedback on a point-diff basis directly in LP. Implementation considerations: All of the functions to save such and object, export them, see a list of them and approve them, could be put in a menu somewhere and hence shouldn't introduce any "UI-cluttering". The other thing to consider is strain on the databases and servers. I imagine that suggestions are already stored os some sort of an object so such point-diff could consist simply of a list of objects which db-wise should be relatively light. Making the real text diffs for the export can be calculated relatively lightly on request and therefore does not have to be saved. With the two suggestions above it would be possible to implement several different work flows, depending on how much of the work you want to do directly in LP, and do it in a way that would be both simple for newcomers and be light in administrative duties. I have scetched two different work flows below, one which is very close to an upstream mail-list-proofread/SVN method and one which is purely LP. 1) * When a translator wants to update a translation you advise him to look at all the strings that need attention and either make suggesions in his own or sign of on other peoples * After this he saves all this work as a point-diff, exports it and sends it to a mail-list for review * He gets feedback and corrects the strings that needs corrections and make a new point-diff and sends the name of the new point-diff to the mail-list * The admin finds this latest point-diff and approves it i
Re: Rosetta-Feedback - UDS Prague
Hi Sebastian, Thanks for taking the time to write this down. Прошле среде у 10:02, Sebastian Heinlein написа: > Hello Arne, Jerome, Danilo and Ubuntu translators, It's Jeroen :) > at UDS Prague I had a short discussion with Arne and other translators > about Rosetta and the general translation process. Here is a summary of > the raised issues. > > 1. Policies > > As far as I know Canoncial wants to target a Wikipedia-like approach > with Rosetta: Many people provide suggestions and correct each other > with a kind of quality assurance through the translation team. This > policy could be perhaps ok for translations with very few upstream > translations, but it doesn't scale for the majority of the European > languages. I'd disagree. In practice, we've had quite a few problems with our past implementation, but I think in the end, we can get there. Of course, it would be much faster if we didn't have to fight past problems at the same time, but that's how life goes. (note that we do have stricter privilege levels: it's just that Ubuntu is using a relatively open one) Also, we do have plans to improve the experience and make it all easier and more natural. See "find-programs-to-translate" spec for a bunch of plans we've got there (i.e. it will be easy to see what requires your attention), it's already easier to see what has someone worked on (i.e. you can see only a single person's contributions per PO file) and evaluate quality of his suggestions/translations. Note that I am not speaking without any experience: I am an upstream GNOME translator, and also GNOME Translation Project spokesperson. I.e. I do care about how we work with upstream. > As western Ubuntu translators we only have to translate a small subset > of packages, basically the ones written under the Ubuntu umbrella, and > the documentation. Furthermore we have to spot for import errors and > keep an eye on single missing or changed strings. What we want to avoid > is a brain split between upstream and Ubuntu translations. For this task > we only need a team of about 5 to 10 active translators, who are capable > and interested in polishing. Indeed, this is something where we need better sync with upstream translations for it to be practical: i.e. as long as what you see in Launchpad are the latest translations from upstream, I don't see any problem with current Launchpad approach. Of course, some minor UI improvements are to be done (like grouping packages into ubuntu-desktop, kubuntu-desktop,...), and we are planning on doing them, but it all takes time. > So the education of good translators is more important to us than > getting a huge number of translated strings (of questionable quality). That's what's important for any team. It has been my opinion that we have so far lacked important features in Launchpad Translations so far > Furthermore it is also very time consuming to review and approve > suggestions. I don't see a real speedup compared to writing them on my > own. Especially since there is no way to provide feedback to the > translators in Rosetta. If there is no contact outside of Rosetta I have > to correct the same errors again and again. I believe the lack of documentation is to blame here. Reviewing suggestions would not speed you up short-term, but once you have reviewed enough of someone's translations and start considering him a good translator, you'd make him a reviewer as well, and then it would be two of you translating, and two of you reviewing. I admit we lack the contextual communication capabilities, and it's been a while since we looked at it (we have a bug about having discussions per-messages, but that seems too fragile imho [bug 25]: i.e. it would be easy to miss any responses, unless a lot of care is taken to present them to translators and reviewers in a nice way). > 2. Review instruments > > Although Rosetta provides some reviewing features there are still some > issues. > > At first a changed and approved suggestion gets submitted under the > approver's name and the original suggestion gets lost. This makes it > impossible for the original submitter to see what was changed. > Furthermore his or her credits get lost. I am not aware to which extend > this is a bug. This is mostly a practical issue. It's impossible to perfectly decide when a certain submission is worthy of being marked as a new one, so we are doing just the extremes: either you accept the suggestion as-is, or you modify it and submit it as your own. I don't want to add more complexity to our translating/review interfaces to provide a checkbox along the lines of 'this is a small change', but I'd be happy to look into automatically detecting typo-fixes and maybe even terminology changes. Anyway, I'd never lean on going all the way: keeping all versions of a translation with contextual marking of who did what change and similar. That would unnecessarily complicate everything, and I believe it would be for little gain (we are
Re: Rosetta-Feedback - UDS Prague
2008/6/11 Sebastian Heinlein <[EMAIL PROTECTED]>: > Hello Arne, Jerome, Danilo and Ubuntu translators, Hello. > at UDS Prague I had a short discussion with Arne and other translators > about Rosetta and the general translation process. Here is a summary of > the raised issues. Yep, unfortunately I left for the airport before the session. I've just a few additional comments and tips that I was aiming to share, and also an English translation of our home page. > So the education of good translators is more important to us than > getting a huge number of translated strings (of questionable quality). Yes, definitely. The most important parts to do in Rosetta is checking for highly visible omissions in translations (new strings not in upstream, or possible import errors), translating *ubuntu-docs and checking that translation do not diverge from upstream translations. Contributing back to upstream when such stuff is done in Rosetta is necessary, too. All that requires quite educated use of Rosetta and other tools. > As far as I know the Finnish team made a manual clean up of their > translation. But to be honest this involves a lot of click-click work > and I am not sure if I find anybody who is willing to do so for the > German translation. Yes. What I did was to use URL https://translations.launchpad.net/ubuntu/hardy/+lang/fi?batch=1500 , when it still worked in the previous LP version, sorted the whole by the "Changed" column and went through each translation that had 1 or more string changed from upstream. It was a relatively huge job, clicking one by one "Packaged" on each template's each changed string, but in the end I had reviewed that the changed strings left were actually necessary, and also such that were contributed in newer upstream versions so that they will be marked "Packaged" in the next Ubuntu again. The effort would be nearly impossible for those languages that had more of the "wild times" in the early Launchpad / Rosetta times when some teams accepted everyone (hundreds!) on the language team and there was _no_ way to do QA. For some very largely changed templates, I took the upstream PO file and simply uploaded it as the "User upload" (since Public upload doesn't overwrite Launchpad changes). That's a way to revert big problems in specific packages, though at the same time one might overwrite some good changes with regards to upstream translations. Regarding QA, that batch=1500 URL was the only easy way to do QA also, since the only QA method in Rosetta is sorting by the "Last Edited" column and looking through what was changed. Now that the batch size was limited, I use a bookmark folder with five links like https://translations.launchpad.net/ubuntu/hardy/+lang/fi?start=0&batch=300 and https://translations.launchpad.net/ubuntu/hardy/+lang/fi?start=300&batch=300 etc. These methods I use to keep Finnish translations in good condition speak also about the clear problems in Rosetta, though by knowing these tricks helps of course. Until a year ago Rosetta was also so broken that the "Changed" column didn't really work, so the first time it was possible to systematically fix broken translations for Ubuntu was for the gutsy release. Anyway, Sebastian had so good points I won't go on commenting all of them. Just wanted to share some of what I've done to keep things in shape - Finnish translations are currently in a rather good shape in hardy. We also have a list of requirements for any potential new translations on our home page, which has proved to be good enough so that the new people on the team are sufficiently capable and communicative. Especially the part about writing something about itself on one's Launchpad page has been a good measurement about whether the applicant has read the home page or not :) Sebastian asked me at UDS-Prague (if I recall correctly, it was in the bar) to list them in English, so I'll just translate the whole home page more or less. The text below is written by me and in public domain. --- = Ubuntu Finnish translators = Ubuntu Finnish translators translate Ubuntu into Finnish. Translating Ubuntu in Rosetta is most useful a month or two before the next Ubuntu's release, when all pieces are in place but some translations are missing. Before this it's useful to participate eg. GNOME (gnome.fi) or KDE (kde-fi.org) translation projects. [a chapter about only "main" being in Rosetta, and "universe" packages are always translated in upstream projects] Group's mailing list is at https://lists.ubuntu.com/mailman/listinfo/ubuntu-l10n-fin - each member should join it. [a chapter about current situation, eg. link to Rosetta's hardy translations and saying that until August-September it's recommended to join upstream translation projects so that 8.10 translations are as complete as they can get, coming from upstream - at the same time translations are not forgotten to be sent to upstream when they are done in upstream] Note! Translator group's membership la
Re: Rosetta-Feedback - UDS Prague
Hi Sebastian, Il giorno mer, 11/06/2008 alle 10.02 +0200, Sebastian Heinlein ha scritto: > Hello Arne, Jerome, Danilo and Ubuntu translators, > > at UDS Prague I had a short discussion with Arne and other translators > about Rosetta and the general translation process. Here is a summary of > the raised issues. Thanks for sharing with us! > 1. Policies > > As far as I know Canoncial wants to target a Wikipedia-like approach > with Rosetta: Many people provide suggestions and correct each other > with a kind of quality assurance through the translation team. This > policy could be perhaps ok for translations with very few upstream > translations, but it doesn't scale for the majority of the European > languages. If a translation team is completely open, this kind of approach, from my POV, could be more error prone. Lots of suggestions from first time contributors and translators that don't know the guide lines that a translation team could have and this could also lead to some upstream upset (that I have already heard even for a closed/moderated team). The idea behind this approach is great: translations, in term of translated strings, could get a boost, no doubt... but is possible that quality could decrease (this isn't the case if all people involved know about guide lines, upstream-downstream... but this usually happens only in a very-perfect-world). > As western Ubuntu translators we only have to translate a small subset > of packages, basically the ones written under the Ubuntu umbrella, and > the documentation. Furthermore we have to spot for import errors and > keep an eye on single missing or changed strings. What we want to avoid > is a brain split between upstream and Ubuntu translations. For this task > we only need a team of about 5 to 10 active translators, who are capable > and interested in polishing. For the Italian team, we are in 2-3 people doing this kind of work: keeping an eye on upstream (me and others are GNOME and TP contributors and manly my translation effort is with upstream, trying to minimize downstream delta) and doing some "seek-and-revert" work. > So the education of good translators is more important to us than > getting a huge number of translated strings (of questionable quality). I completely agree: it's better to have less but well translated strings than lots of not so high quality. It would be great to have a 100% translated system, but that's something that needs and takes time... lot of... > Furthermore it is also very time consuming to review and approve > suggestions. I don't see a real speedup compared to writing them on my > own. Especially since there is no way to provide feedback to the > translators in Rosetta. If there is no contact outside of Rosetta I have > to correct the same errors again and again. > > 2. Review instruments > > Although Rosetta provides some reviewing features there are still some > issues. > > At first a changed and approved suggestion gets submitted under the > approver's name and the original suggestion gets lost. This makes it > impossible for the original submitter to see what was changed. > Furthermore his or her credits get lost. I am not aware to which extend > this is a bug. Pros and cons here too. If we have to keep all suggestions, probably the interface will result in a complete chaos. I don't know what could happen if ten people make ten different suggestions (maybe only for a typo) for all the strings in a page... if i have to review those strings, yes, it will take me less time to translate them from ground up. But as you said, we loose track of the review process... > Furthermore high lightening the changes between suggestion and approval > would make them more visible. Mostly there are wrong terms, typos or > grammar issues. That would very precious, indeed, something like Pootle (I use Pootle for Compiz translations) does and it's very useful in reviewing suggestions. > Secondly it would be nice to have a kind of comment field for changed > suggestions. +1 for this too! Translators comments are very very useful (Pootle supports them). I don't know the implications that could have inserting comments inside LP-Rosetta (DB tables, code, whatever...), but that would be of great value. > Currently I have to open up a chat window or write on a > wiki page all the changes with comments to provide feedback to a new > translator. This involves a lot of copy and paste work. When I review translations from new translators (something that doesn't happen that much though, probably because people get a little scared with the high demanding skills and quality and all the documents that we want them to read...) I report them my impressions, the strings numbers that I changed and what I changed... yes, it's a time consuming task... but I think that reviewing is not that easy anyway, even with the best solution at hand. > 3. Quality assurance > > For the German team I would like to limit the persons
Re: Rosetta-Feedback - UDS Prague
I'm in agreement of all the points you have made. In Hebrew Translators Team we've also discussed some of those issues. The biggest problem as I see it is (and as you said) that there is no good translation resource for guidelines and FAQ. Also, there seems to be no way of knowing when new suggestions are submitted in Rosetta. And for two teams of suggestion and approval: we for example won't need suggestion team since we don't have much volunteers in general. Eyal On Wed, Jun 11, 2008 at 11:02 AM, Sebastian Heinlein <[EMAIL PROTECTED]> wrote: > Hello Arne, Jerome, Danilo and Ubuntu translators, > > at UDS Prague I had a short discussion with Arne and other translators > about Rosetta and the general translation process. Here is a summary of > the raised issues. > > 1. Policies > > As far as I know Canoncial wants to target a Wikipedia-like approach > with Rosetta: Many people provide suggestions and correct each other > with a kind of quality assurance through the translation team. This > policy could be perhaps ok for translations with very few upstream > translations, but it doesn't scale for the majority of the European > languages. > > As western Ubuntu translators we only have to translate a small subset > of packages, basically the ones written under the Ubuntu umbrella, and > the documentation. Furthermore we have to spot for import errors and > keep an eye on single missing or changed strings. What we want to avoid > is a brain split between upstream and Ubuntu translations. For this task > we only need a team of about 5 to 10 active translators, who are capable > and interested in polishing. > > So the education of good translators is more important to us than > getting a huge number of translated strings (of questionable quality). > > Furthermore it is also very time consuming to review and approve > suggestions. I don't see a real speedup compared to writing them on my > own. Especially since there is no way to provide feedback to the > translators in Rosetta. If there is no contact outside of Rosetta I have > to correct the same errors again and again. > > 2. Review instruments > > Although Rosetta provides some reviewing features there are still some > issues. > > At first a changed and approved suggestion gets submitted under the > approver's name and the original suggestion gets lost. This makes it > impossible for the original submitter to see what was changed. > Furthermore his or her credits get lost. I am not aware to which extend > this is a bug. > > Furthermore high lightening the changes between suggestion and approval > would make them more visible. Mostly there are wrong terms, typos or > grammar issues. > > Secondly it would be nice to have a kind of comment field for changed > suggestions. Currently I have to open up a chat window or write on a > wiki page all the changes with comments to provide feedback to a new > translator. This involves a lot of copy and paste work. > > 3. Quality assurance > > For the German team I would like to limit the persons who are allowed to > make suggestions for out of two reasons: At first I would like to force > them to get into contact us before working on the translation to help > them to improve their quality, see above. Secondly most suggestions just > get not approved since they have not been done systematically enough to > send them to upstream. Personally I won't accept translations for > non-Ubuntu projects if I don't know that the translator will cooperate > with upstream. Currently many people just start to translate and in the > end waste their time, since the output does not meet the standards. This > is a pity. And I always have a bad feeling telling the people so. > > Therefor I would support splitting the team into two parts: a translator > team who is allowed to only make suggestions and an approver or qa team. > This issue has been discussed for ages now. I remember talking with > Carlos about this on my first UDS Paris back in 2006. I don't want to > enforce this structure for all teams, but I know of some teams who would > welcome this more fine grained privilege system. > > 4. Upstream collaboration > > Are there any plans to support a version control system import/export > like in the RedHat tool? Or to generally improve the system? What is the > status on automatically importing from upstream version control system > (GNOME, KDE)? > > 4. Import issues > > If you take a look at the German translations [1] you will notice a lot > of packages with only one to ten changed terms in Launchpad. In many > cases these are import errors, since the submitter and approver are > registered automatically in Launchpad (e.g. Sascha Herres and Karl > Eichwalder for the German gettext translation [1]). > > As far as I know the Finish team made a manual clean up of their > translation. But to be honest this involves a lot of click-click work > and I am not sure if I find anybody who is willing to do so for the > German translation. > >
