Re: Apostrophe in date format in Ubuntu/Gnome
Thanks Adi, I'm agree. I just wanted know if there was a little solution for that issue, and no create new problems in translations. Regards Iñigo Varela. El llu, 07-12-2009 a les 22:56 +0200, Adi Roiban escribió: > În data de Lu, 07-12-2009 la 21:39 +0100, Iñigo Varela a scris: > > In Asturian language, like in English, is common the use of Apostrophe, > > i.e. (I am--> I'm; do not-->Don't) > > In this way, Asturian use Apostrophe with word "de", when the following > > word begins with vowel: > [snip] > > %a, %e de %b -> llu, 7 de avi (mon, 7th of dec), instead of correct > > form that must be "llu, 7 d'avi" > > > > Obviously, this format works for a few months, but it doesn't work in > > abril (April), agostu (August), ochobre (October), and avientu > > (December) > > > > How can we do for use the apostrophe with the name of months that begins > > with vowel? Any language with same problem? > > > There are similar problems with vowel exceptions in other languages. > > As far as I know there is no trivial/feasible solution and while "7 de > avi" is still correct, I don't think we need to add complexity in the > system. > Many translators are puzzled by plural forms, adding vowel exceptions > could cause more problems than solutions. > > Cheers > > -- > Adi Roiban > > -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Apostrophe in date format in Ubuntu/Gnome
În data de Lu, 07-12-2009 la 21:39 +0100, Iñigo Varela a scris: > In Asturian language, like in English, is common the use of Apostrophe, > i.e. (I am--> I'm; do not-->Don't) > In this way, Asturian use Apostrophe with word "de", when the following > word begins with vowel: [snip] > %a, %e de %b -> llu, 7 de avi (mon, 7th of dec), instead of correct > form that must be "llu, 7 d'avi" > > Obviously, this format works for a few months, but it doesn't work in > abril (April), agostu (August), ochobre (October), and avientu > (December) > > How can we do for use the apostrophe with the name of months that begins > with vowel? Any language with same problem? > There are similar problems with vowel exceptions in other languages. As far as I know there is no trivial/feasible solution and while "7 de avi" is still correct, I don't think we need to add complexity in the system. Many translators are puzzled by plural forms, adding vowel exceptions could cause more problems than solutions. Cheers -- Adi Roiban -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Apostrophe in date format in Ubuntu/Gnome
In Asturian language, like in English, is common the use of Apostrophe, i.e. (I am--> I'm; do not-->Don't) In this way, Asturian use Apostrophe with word "de", when the following word begins with vowel: ASTURIANENGLISH 19 de xineru(19th of January) 19 de febreru (19th of February) 19 de marzu (19th of March) 19 d'abril (19th of April) 19 de mayu (19th of May) 19 de xunu (19th of June) 19 de xunetu(19th of July) 19 d'agostu (19th of august) 19 de setiembre (19th of september) 19 d'ochobre(19th of october) 19 de payares (19th of november) 19 d'avientu(19th of december) Today is 7th of december, and in my calendar I can see "7 de avi". The correct form should be: "7 d'avi". I have found in gdm and gnome-panel that the format for date is: %a, %e de %b -> llu, 7 de avi (mon, 7th of dec), instead of correct form that must be "llu, 7 d'avi" Obviously, this format works for a few months, but it doesn't work in abril (April), agostu (August), ochobre (October), and avientu (December) How can we do for use the apostrophe with the name of months that begins with vowel? Any language with same problem? -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: GNU Grub
El dl 07 de 12 de 2009 a les 10:59 +0100, en/na Iñigo Varela va escriure: > Yes, I'm interested in translate only this text: > > "Use the (up) and (down) keys to select whic entry is highlighted." > "Press enter to boot the selected OS, 'e' to edit the" > "commands before booting, or 'c' for a command-line" > > > Thinking only in users, I know that there are a lot of users that don't > speak english, so this text should be translated... I know that Carles Piña (on CC) has been doing great work in trying to get this implemented upstream [1][2][3][4], so I'd recommend anyone interested in getting GRUB2 translatable to give him a hand or expand the discussion at grub-devel (at) gnu (dot) org. Thanks! Regards, David. [1] http://lists.gnu.org/archive/html/grub-devel/2009-01/msg00082.html [2] http://lists.gnu.org/archive/html/grub-devel/2009-01/msg00118.html [3] http://lists.gnu.org/archive/html/grub-devel/2009-04/msg00181.html [4] http://www.mail-archive.com/grub-de...@gnu.org/msg13899.html (This is just a sample, if you want to follow the current status, search for 'gettext' in the list or subscribe to it.) -- David Planella Ubuntu Translations Coordinator david(dot)planella(at)ubuntu(dot)com www.ubuntu.com signature.asc Description: Això és una part d'un missatge signada digitalment -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Ubuntu Translation bug handling process
Hi Sense, First of all, thanks a lot for the feedback. We really appreciate this, since bug handling is a new process for the translations team and any comments, especially from experienced bug squad members, are really useful to us. Let me give some background on the purpose of the ubuntu-translations project for translations bug reporting. As you probably know, unlike other teams (e.g. kernel), translations cannot be reported against a single package (not even language packs (*)). This, and the facts that a) knowledge on how to handle or fix translations is currently scarce and b) translations has been an aspect traditionally not too well looked after, lead to the situation that many translations bugs were simply forgotten in the past, although many members of the translations community would have been willing to actively triage them and in some cases also fix them. In the past, the i18n or l10n tags had been used on an occasional basis, but as in Launchpad you cannot subscribe to a tag, it was not possible for those interested in monitoring and acting upon translations bugs to have an overview of the whole picture. With the ubuntu-translations project we've now got a hub for translations bugs: this allows those interested in them to get an overview of currently open bugs, having a team (the Ubuntu Translations Coordinators) behind it -both actively triaging and fixing them and acting as a point of contact- and permitting further community participation subscribing to bug mail. Another compelling reason for using it was to decouple bugs related to Ubuntu translations from bugs in the Launchpad Translations component. Very often bugs in the distro were reported against Rosetta, and there was not a clear path for the Rosetta developers to bring them back to the distro. Now they only have to move them to ubuntu-translations, and if necessary we open tasks for the appropriate packages. We are still learning about the bug triaging process for translations, and in that respect we've been documenting it and asking for feedback from the bugs team: https://help.ubuntu.com/community/ReportingBugs#Filing%20translation% 20bugs https://wiki.ubuntu.com/Translations/KnowledgeBase/ReportingBugs https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs Note that this is still work in progress, e.g. the last two documents should probably be merged into HandlingBugs, which is currently a brainstorm page for defining the process. That's one of the reasons (not having a defined process) we hadn't widely announced the project yet, but after the experience from the last cycle and your original suggestion on a Hug Day on language packs, I thought it might be time to move this forward, give it a road test during the Hug Day and get some more feedback. Needless to say, we are open to suggestions and willing to follow the standard practices of the bug squad. I feel that this has worked extremely well for the Karmic cycle. I do not have statistics at hand other than [1], but judging by the number of bugs we've processed and the status of the release (also comparing it to previous ones), I think this has been one of the main achievements of last cycle in terms of better translations QA. El dj 03 de 12 de 2009 a les 20:27 +0100, en/na Sense Hofstede va escriure: > Hello, > > Browsing the BugDay of this day[1] I can't help but feel that a lot of > these bugs have appeared on the list because the ubuntu-translators > project doesn't want to use or cannot set importance and the Triaged > status. I suspect the latest. Neither of those, it's because we (well, at least me) didn't quite know the difference between Confirmed and Triaged. I'd be more than happy to use the same convention from https://wiki.ubuntu.com/Bugs/Status for the ubuntu-translations project, and start marking the current Confirmed bugs to Triaged as appropriate. > This means that the status of the bug reports that are mainly handled > by Ubuntu Translators will continue to pop up on search results like > the one used for the lists of this BugDay. > Another thing I noticed in the Hug Day is that only members of the ubuntu-translations-coordinators team can change the status to triaged - is there a way we could give this ability to the bugsquad team as well? Would that be desirable? > The triaging process for translation bugs is further complicated by > the requirement to report it both against the source package of the > affected application and the ubuntu-translations project. This forces > us to maintain two sets of statuses, each subject to the rule of a > different team. This causes confusion. > Although we do not make it a requirement, it is true that in most of the cases there is a separate task for the package. While I see some of the disadvantages in that, I cannot think of any other way of keeping track of translation bugs as a whole and at the same time have the bugs reported or fixed in the package. > Then there is the problem of t
Re: GNU Grub
Yes, I'm interested in translate only this text: "Use the (up) and (down) keys to select whic entry is highlighted." "Press enter to boot the selected OS, 'e' to edit the" "commands before booting, or 'c' for a command-line" Thinking only in users, I know that there are a lot of users that don't speak english, so this text should be translated... Regards, Iñigo Varela. malditoas...@gmail.com https://launchpad.net/~malditoastur El llu, 07-12-2009 a les 11:20 +0200, Khaled Hosny escribió: > This seems to be translations for the various command line tools shipped > with grub, not the actual bootloader that displays the message > malditoastur was asking about. > > Regards, > Khaled > -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: GNU Grub
On Mon, Dec 07, 2009 at 07:55:21AM +0100, Gabor Kelemen wrote: > Khaled Hosny írta: > >On Mon, Dec 07, 2009 at 12:56:27AM +0100, malditoastur wrote: > >>I would like to translate the following strings in GNU Grub for Karmic: > >> > >>"Use the (up) and (down) keys to select whic entry is highlighted." > >>"Press enter to boot the selected OS, 'e' to edit the" > >>"commands before booting, or 'c' for a command-line" > >> > >> > >>...but I don't know where I must start. Is possible translate it in > >>Launchpad? > > > >AFAIK, grub2 isn't localizable (i.e. the strings are hardcoded in the > >source and no support for loading translation catalogues.) > > > >Regards, > > Khaled > > > > > This changed recently: http://translationproject.org/domain/grub.html This seems to be translations for the various command line tools shipped with grub, not the actual bootloader that displays the message malditoastur was asking about. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer signature.asc Description: Digital signature -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: GNU Grub
2009/12/7 Gabor Kelemen : > This changed recently: http://translationproject.org/domain/grub.html That textdomain is not GRUB intended as "the GRUB you see when you boot". Those strings refer to the command line utilites from GRUB2. The i18n of GRUB2 is in the TODO list of the developers, but not implemented yet: http://grub.enbug.org/AboutInternationalization Ciao. -- Milo Casagrande -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Ubuntu Translation bug handling process
Hello, Browsing the BugDay of this day[1] I can't help but feel that a lot of these bugs have appeared on the list because the ubuntu-translators project doesn't want to use or cannot set importance and the Triaged status. I suspect the latest. This means that the status of the bug reports that are mainly handled by Ubuntu Translators will continue to pop up on search results like the one used for the lists of this BugDay. The triaging process for translation bugs is further complicated by the requirement to report it both against the source package of the affected application and the ubuntu-translations project. This forces us to maintain two sets of statuses, each subject to the rule of a different team. This causes confusion. Then there is the problem of the difference between translations made at Launchpad and translations made upstream. Some bugs have to be fixed here, some have to be forwarded upstream. I suggest to make the process of reporting more clear by implementing the following changes: 1. The starting point of all translation bugs -- unless you know better already -- can still be the source package of the affected application. 2. No extra tasks for bugs in upstream translations, this only adds extra clutter to the overview, generates extra mail noise and generates more work and confusion. 3. Bugs in translations done at Launchpad should be reported against ubuntu-translations and keep the source package task, because: 4. The source package task is for maintaining the status of the bug concerning the system -- i.e. if the bug has been Triaged(=reported properly upstream or at ubuntu-translations) or if the Fix is Released -- the ubuntu-translations task should be for the status of the fix in Rosetta or the team only 4b. This means that translation bugs always need to be 'forwarded upstream', be it to real upstreams or to ubuntu-translations. This is what the triagers should focus on when triaging these bugs. 5. Responsible for setting the status in ubuntu-translations are their (appointed?) members, responsible for the source package task is Bug Control (and the Bugsquad). Some members of ubuntu-translations that are very active on Launchpad/Malone could be granted membership of Ubuntu Bugcontrol -- if they don't already are a member -- to make it easier for them to manage the source package tasks. 6. Use the Triaged status for the source package when the Bugsquad doesn't need to do any work on it anymore! These points don't add a lot of new stuff, but things would be a bit clearer if both teams would agree on them and integrate them into the documentation. [1] https://wiki.ubuntu.com/UbuntuBugDay/20091203 Regards, -- Sense Hofstede /ˈsen.sɜː ˈhɒf.steɪdɜː/ -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
