Re: Creating Sundanese Laguage Translation
Hi Ilham,
It's great to see interest in translating to Sundanese language. Please
follow the guidelines regarding naming the team ("ubuntu-l10n-su") and
having appropriate permissions as described on
https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam
After the team is set up properly, we'll make it part of the Ubuntu
Translators group.
https://translations.launchpad.net/+groups/ubuntu-translators
Also be sure to provide all the relevant details for the Sundanese
language (like plural forms and such: it's all documented on
StartingTeam page, and we need it to fill in missing bits of
https://translations.launchpad.net/+languages/su)
While it's not a blocker for starting translations in Launchpad for
Ubuntu, your translations will be useless until you also ensure there is
a "locale" definition for Sundanese (su_ID, look at eg.
/usr/share/i18n/locale/id_ID as an example of one). These need to be
pushed into GNU libc.
Cheers,
Danilo
Дана 07.08.2017., у 07:55, Ilham Nurwansah је написао/ла:
Dear Ubuntu Translation Coordinator,
Firstly I would like to introduce my self. My name is Ilham, live in
West Java, Indonesia where the people mostly speak in Sundanese (su)
language. Sundanese is the second largest language spoken in
Indonesia. For several years, I've tried to contact you to try to make
the translation of Sundanese.
I hope there's a way to make it possible. I see that the Indonesian
and Acehnese has existed in translation project on the Launchpad. I've
made a team to do the Sundanese translation project
(https://launchpad.net/~sundanese
), and it still need approval from
you.
Pleas let me know if there any condition to make the Sundanese
translation available for Ubuntu. I'll try my best to fulfill it.
Best wishes,
Ilham
--
ubuntu-translators mailing list
ubuntu-translators@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: New translation for Ubuntu
Hi Demuxer, It would be great to see Kaqchikel as one of Ubuntu languages! On top of the pointers others have shared, here're a few more. The most important things to start on are: - locale for the language - fonts if anything special is needed for display purposes (it seems generic multilingual Latin Unicode fonts like Ubuntu font or DejaVu font should work well) - keyboard layout so you can enter the translations more efficiently Long ago when I started on Serbian translations, I've gone through the entire dance, and presented that at GUADEC. Here are the still relevant notes if you are starting from scratch: http://kvota.net/guadec/localised-desktop-talk/ Note that it may be hard to get a locale into GNU libc, but Debian has an extended locales package that is much easier to get into. I can help create a language on Launchpad using the ISO-639-3 code "cak", which will allow you to start translations. I've entered the few basic bits, but I still need the following: - Name of the language as spelled in Kaqchikel - Plural forms: basically, do any words change in a more complex manner when they are next to a number, or is it a simple, English/Spanish-like singular and plural (eg. "1 thing", "7 thing*s*"; Serbian and most Slavic languages have a few more forms, eg. we basically say "21 thing" and not "21 things"). You should also set up a team as explained on https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam page. У пет, 02. 06 2017. у 13:49 -0600, Demuxer @gmail пише: > > What is the first step? > Is it possible to have a branch from the SPANISH - LATAM ? the > translators are better with spanish than english, of course this > would change in another Ubuntu Release, but we prefer 'spanish' as a > base. You can use Launchpad to help you by using another language as a guide. Make sure you add all the languages that you wish to translate to or use as a guide at https://translations.launchpad.net/people/+me/+editlanguages Then browse to a translation page that you'd like to contribute to, and select "Spanish" as the guide language just before the translations really start. Eg. for the unity-greeter, which is the login screen that shows up when you turn Ubuntu on, you can go to: https://translations.launchpad.net/ubuntu/xenial/+source/unity-greeter/+pots/unity-greeter/cak/+translate?start=0=10=all_language=es_language-empty-marker=1_show=all (if you hit a timeout, retry a few times since this functionality is not often used and Launchpad needs to load it into cache for it to perform better). Once you have a locale created and installed on the system, you can also make the system default to Kaqchikel and fall back to Spanish. Using LANG or LANGUAGE environment variables can help with that. Also, be aware that you'd only be submitting suggestions until you finish with setting up a team and it gets assigned official status. Good luck, and welcome aboard! Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Localize uNav 0.65 (Full localization option) (Costales)
У уто, 17. 01 2017. у 18:43 +0100, Costales пише:
>
> 97. " By"?
>
> Author of a custom voice.
> For example: English. By Nathan.
This is, in general, a very bad string composition approach.
For translations, it's best to do something like the following:
"{language}. By {author}."
(or "%s. By %s." with a comment/context explaining what the first and
second %s are)
The reason is that some languages might have a different word order,
might not even have "by" and so forth.
Cheers,
Danilo
--
ubuntu-translators mailing list
ubuntu-translators@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Utopic plurals
Hi all, FWIW, I've filed a couple of plural forms bugs: https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1363401 https://bugs.launchpad.net/telephony-service/+bug/1363386 https://bugs.launchpad.net/camera-app/+bug/1363377 and also one unrelated to plural forms https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1363404 There're a lot more string composition problems, but that'll have to wait for when I have more time to investigate them properly. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: UDD up-to-date
Hi Martin, У сре, 09. 11 2011. у 15:27 +1100, Martin Pool пише: We're in the middle of a fairly epic series of roll-outs to the Launchpad buildds. Done today, both on staging and production, is an update to bzr 2.4, which should let large trees be assembled in recipe builds without running out of memory. Great to hear, thanks for passing the news on! Cheers, Danilo -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: ibus template problem
Hi Iñigo, У нед, 09. 10 2011. у 14:15 +0200, Iñigo Varela пише: Anyone know why the ibus template always appears incomplete for 'ast' and 'lv' languages? I see that in other languages it's possible complete it, (ca, da, nl, fr, de, it, hu, pt, es, ) The string translator-credits it's not editable, so I don't know what's happening... https://translations.launchpad.net/ubuntu/oneiric/+source/ibus/+pots/ibus It's a bug in Launchpad[1]. The way to complete it is to have the string translated upstream and then let the import trickle downstream. We are sorry this is making it harder for you, but it is in fact fully translated properly, so until we find time to fix it, you will, unfortunately, have to live with it as is :( [1]https://bugs.launchpad.net/launchpad/+bug/503421 Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations are not properly imported into Launchpad.
Hi Andrius, У сре, 05. 10 2011. у 23:10 +0100, Andrius Štikonas пише: I have noticed that sometimes Launchpad does not correctly import upstream translations. I have noticed this with KDE translations of Lithuanian language. For example, https://translations.launchpad.net/ubuntu/oneiric/+source/kde-workspace/+pots/powerdevilglobalconfig/lt/+details says that there are no differences between Ubuntu and upstream ( http://websvn.kde.org/*checkout*/branches/stable/l10n-kde4/lt/messages/kdebase/powerdevilglobalconfig.po) but e.g. string https://translations.launchpad.net/ubuntu/oneiric/+source/kde-workspace/+pots/powerdevilglobalconfig/lt/34/+translate still uses old upstream translation and the new one is only a suggestion (which contradicts the fact that there are no differences with upstream) . I filed a bug about what I believe might be the problem: https://bugs.launchpad.net/launchpad/+bug/869264 I am not entirely sure this is the whole root cause, but this is one likely way that I see this happening. If you are certain this is not the case here (i.e. there was no KDE package upload in any of the Ubuntu series after the Oneiric upload), please file a new bug about it! There were more examples in https://translations.launchpad.net/ubuntu/oneiric/+source/kde4libs/+pots/libplasma/lt/ although I have already fixed them in Launchpad because these strings are very visible to the end user. Or e.g. https://translations.launchpad.net/ubuntu/oneiric/+source/kdenetwork/+pots/kopete/lt/1540/+translate Current translation is an old upstream translation while the new one is only a suggestion. Sometimes, these examples will still be there on staging and/or qastaging, which are only refreshed from production every once in a while. So, mentioning these links in a bug report might still be useful! There are a lot more examples, so it is not possible to list them all. It seems to me that at lease KDE Lithuanian translations are no longer properly imported. Maybe somebody can tell if this happens with other languages or with non KDE translations. Unfortunately, I do not have time to look at this issue more thoroughly. At the very least, please file a bug: if you don't have time to look at it, yet you are certain they are not imported properly, somebody will have to look into it :) Also, note that Launchpad imports KDE translations from *packages*, so please first ensure that KDE packages (tarballs) shipped in Ubuntu have these translations. Ideally, we should be able to import translations from upstream directly, but this has not been implemented for KDE yet, and is not fully deployed for GNOME either. Finally, Ubuntu relies on its users to report bugs for it to become better. The same holds true for Launchpad: there is only so many problems that we can find ourselves! Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations are not properly imported into Launchpad.
Hi Jiri, У чет, 06. 10 2011. у 10:05 +0300, Jiri Grönroos пише: This is a serious issue and it's not limited to one specific language. I believe it affects all projects hosted on Rosetta/LP. A bug has been filed, see https://bugs.launchpad.net/launchpad/+bug/818230 - please add your examples/observations there. I appreciate that you have filed this bug. I have replied there and split the bug into two because I believe they are internally two different problems. However, on re-reading this, you seem to describe a third issue as well: an upstream translation that you have already changed is changed back? It could be due to the problem described in https://bugs.launchpad.net/launchpad/+bug/869264 but it could also be a different problem. Please add a comment to this bug describing this as well, and sorry if I misread your original report above. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Not happy at all
Hi Ask, У сре, 22. 12 2010. у 13:01 +0100, Ask Hjorth Larsen пише: It's unfortunate that the `fuzzy' feature of gettext is not supported in LP, and there have been previous discussions in the manual team about what to do, but there's no really good solution as it is. Perhaps we should really just turn fuzzy translations into suggestions. It wouldn't be a big deal for us, but: 1. people *will* mistakenly approve suggestions which look almost the same (imagine someone fixing a typo of a missing not in a long documentation message: I will bet you that most people will not notice the not and will just approve the existing translation); this is a problem even with offline translation, but Launchpad makes it very easy to make this mistake for reviewers 2. if msgmerge was not done prior to the import, there won't be any benefit 3. people will expect this to actually work, and yet it wouldn't (iow, we'll get questions why was there not a suggestion for one string or another, and those questions are nothing but a distraction); today we just get feature requests about this :) Those are the reasons why it's not behaving like that today. We do, however, want to have a smart similarity matching feature for suggestions. That's a lot more work. I'd be happy to guide anyone with some time on their hands into implementing that. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: [Ubuntu-manual] Not happy at all
У сре, 22. 12 2010. у 22:35 +0200, Khaled Hosny пише: On Wed, Dec 22, 2010 at 06:51:15PM +0100, Ask Hjorth Larsen wrote: My opinion on what we need technically: Fuzzy matching and a word-wise po-file diffing utility. Lunchpad developers seem not to think that translators effort and resources is worthy saving, this is not the first time this issue is brought up. Exactly. We hate you and want you to suffer. That's our idea of good time. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Libre Office: A Proposal
У сре, 29. 09 2010. у 08:28 +, Sveinn í Felli пише: -Wrong translations can eventually *break* OOo/LO - make it unusable. There would be much recoding to do before one would accept translations from an open system such as LP/Rosetta. LP/Rosetta is open in the sense that it's free and open source software. Who gets privileges to translate is entirely up to teams and projects. FWIW, there's even a Closed translation policy where only approved translators can contribute anything (including suggestions) to a project's translations. It'd certainly be nice to support LibreOffice natively in Launchpad, but it is a lot of work that we can't take on right now. We'd be very interested to help anyone else who wants to lead the project, though. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: question regarding feedback of launchpad translation suggestions
Hi Tom, Your email doesn't sound directly related to what OP said (in my reading, at least :), but since I am not sure what it refers to and it sounds worrying regarding the Launchpad project, I'd respond to your email directly. У сре, 25. 08 2010. у 11:22 +, Tom Davies пише: I think this is part of a wider problem in Launchpad and one i have complained about to no avail on a few previous occasions. Now that the Translators Team are becoming aware of the problem i have some hope of this getting resolved as you folks seems to be one of the more effective and can do teams. It's really something that needs a dev working alongside someone who has a lot of tact and diplomacy skills which are not necessarily skills vital to being a good dev. When people write to Launchpad Answers or bug-squad it would be good practice (from a customer relations point of view) to send an automated response just to let the person know their question/bug-report has been received. That kind-of happens. When you file a bug, you get an email. In Launchpad team (so, for questions regarding Launchpad usage or Launchpad bugs), we try very hard to keep the number of untriaged bugs at zero, and the same thing for questions. We do it daily (there's always someone taking care of forwarding issues to appropriate places). Since I am not sure where are you seeing many problems like this, if it is indeed in Launchpad itself (i.e. launchpad.net/launchpad-project, launchpad.net/rosetta, ...), I'd be happy to talk it over and see where are we failing. If it's not Launchpad-proper, then I probably can't help much (your email kind of implies that you are talking about Ubuntu, but wording makes me confused a bit with direct references to Launchpad). Also, AFAIK, Ubuntu has a bunch of triaging scripts which do many things automatically. It seems that many devs hate auto-responses on principle but they are better equipped to deal with a total lack of response where many people contacting Launchpad may be completely new to OpenSource Forums and may just decide that Windows support is better. Currently the only auto-response from Launchpad Janitor is a very rude note sent 15days later and the note says something like We cannot be bothered to deal with your question. Go away. Which i feel is a little bit negative and has been written up in external, mainstrem press as a reason why some people try Ubuntu once and then go back to Windows. I think if we have not been able to help with a question or bug-report then we should let that person know of other sites that they could try instead, such as http://www.linuxquestions.org http://www.ubuntuforums.com That might be a good idea. Alternative is to switch off answers application for Ubuntu and just direct people to eg. Ubuntu forums. Do note that Ubuntu QA team is doing a great job making sure this doesn't happen with bugs filed against Ubuntu. But, questions is an entirely different beast altogether. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: question regarding feedback of launchpad translation suggestions
Hi Oier, У уто, 24. 08 2010. у 18:09 +0200, Oier Mees пише: I know I am not the first one with this issue but I would like to know if anybody is working on providing some sort of feedback for people who do translation suggestions on Launchpad. We've had such discussions in the past. It would probably be useful to look at the archives of this list. I can't find the actual thread right now, but I do remember people talking about the approaches they are taking. In general, people do it manually because Launchpad doesn't provide anything else. I.e. they copy-paste strings into emails and then comment inline. Launchpad has a bunch of bugs filed about making this much easier, but not much has happened there because of lack of development resources. Some sort of optional notification when the suggestion gets reviewed would be great because otherwise they can think that their suggestions are ignored and feel that they are wasting their time. Besides an option to inform them about what kind of mistakes they are making for instance would also be good, but I don't know how could this fit without introducing too much clutter in the UI. Yeah, making this all possible from within Launchpad would be best. It does take a lot of effort to implement properly. Since Launchpad is open-source, we'd also welcome any help in implementing by anyone who is able to deal with some coding :) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Translation imports on hold
Hi all, Translation imports are on hold and will remain so for the next 12-16h. This is due to the migration script which completes our deployment of bug #29800[1] (support for language variants), and some unexpected (at least for the LP Translations team :) DB surgery happening at the same time. We apologize for any inconvenience caused by this and by the late notice (we only expected them to be on hold for an hour or two post rollout, but the work on the DB delays that by another 12h or so). Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Is Aptitude upstream?
Hi Khaled, У нед, 01. 08 2010. у 19:03 +0300, Khaled Hosny пише: On Sun, Aug 01, 2010 at 11:38:01PM +0800, Arne Goetje wrote: In general, you should translate any template where translations are still missing, no matter if they come from upstream or they are native to Ubuntu. I think this is a very bad advice actually, we are not helping better localisation by wasting time doing downstream translations that are very unlikely to be used upstream. We should instead encourage Ubuntu translators to communicate with upstream projects to reach a common background. For example, though packages in Ubuntu might be slightly older than current upstream releases, usually the differences are minimal that it is very easy to translate the latest version upstream then backport it to the version in Ubuntu and then fix any differences. I tend to disagree: Launchpad is slightly more powerful tool for translation that what upstreams usually offer, and allows for more collaboration (i.e. it's easy for someone to just fix a typo and submit that for review). Thus, it is very nice to translate in Launchpad and then submit your translations upstream. Benefits of working in Launchpad directly is that users will see translations sooner (they get packaged in Ubuntu), and nobody really loses anything as long as you submit them upstream. This means that there won't be any wasted effort either: you'd just be working in a different direction. However, you'd get the benefit of a bigger pool of contributors Launchpad has over many upstreams, and that should help you get over the limited resources hump. The waste can happen if it happens that there's a very active upstream translator who might do the translation at the same time. But nothing can help with that much: this can happen in an upstream team itself if they are not communicating between themselves. So, you've got to talk to them to coordinate (i.e. an email to an upstream translation team list saying I am translating this should be enough). FWIW, we are working on tools in Launchpad that will enable this process to be even smoother for both directions. This means with next upstream sync, the difference will be zero to very minimal. The next upstream sync, atm, might not really happen in any foreseeable future (if ever). For instance, do you keep GNOME 2.22 translations updated upstream? Yet, Hardy is a LTS and still supported on the desktop, and there are many installations still using it. You can choose to get translations to these users if you translate Hardy directly in Launchpad (see below). Most translation teams are underpowered unpaid volunteers, we need to manage those limited resources for the greater benefit, not wasting time redoing translations and re-reviewing translations. Launchpad should help there as well: it can be used to attract more contributors, and it saves some work. For instance, with our translations sharing feature, you don't have to do the same work twice. Even while you are just updating translations in Lucid, if that package hasn't changed much since Hardy and yet was untranslated in it, Hardy will also get the benefit! So, you don't have to specifically work on Hardy to make the best use of these Launchpad features, and users of your translation will get more benefit. Of course, there are also areas were Launchpad is a bit behind on regular translation processes, but we are working on improving them as well. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Is Aptitude upstream?
Hi Khaled, У пон, 02. 08 2010. у 12:14 +0300, Khaled Hosny пише: But then your work will benefit both Ubuntu and non-Ubuntu users (who did the original translation), just taking others work and not contributing back is very selfish. Also doing an svn co of KDE l10n repository takes no more than few seconds (I know not every translator is comfortable with such tools, but that is why we have team coordinators). Nobody was saying anything about not contributing back. You should contribute back, but that shouldn't stop you from starting with Launchpad, because it does have some cool features. Maybe you personally don't care about them, and that's ok, but we should not discourage people from making their own choice. Also, it would have been simpler if launchpad has a more simple upload/download forms, than the overly and unnecessarily complex ones that currently exist (sending download links by mails that are delayed several hours!) For majority of PO files, we should be able to generate them on request today (we've done a big number of performance improvements which should allow that). However, we simply haven't done the work to switch PO file downloads to happen in such a way. I'd be happy to mentor anyone in getting PO file downloads directly from the launchpad.net (at least for authorised translators), but we don't have time to improve that further right now. Remember, Launchpad.net is open source so you can help fix it as well :) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Testing translation Ubuntu-docs (Lucid)
У чет, 22. 07 2010. у 17:31 +0200, David Planella пише: That's correct, but although we talked about this some time ago, we haven't quite coordinated with the docs team to update the ubuntu-docs, and if I'm not mistaken, there hasn't been any post-release update to the package. If the docs team would like to release an update with new translations, I'd be happy to release a new language pack update shortly after. I might be mistaken, but isn't documentation outside the scope of the language packs? I.e. for documentation updates you've got to rebuild the package with latest translations included. Or, put another way: I think documentation translation updates don't come with regular Ubuntu language pack updates. A new package containing translations needs to be rebuilt. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Synchronization of translations with upstream projects
Hi Krasimir, У сре, 24. 03 2010. у 15:03 +0200, Krasimir Chonov пише: Maybe this question is asked many times. So is there any schedule or anything from which depends when the translations will be synchronized with the upstream projects. Many translations in GNOME on many languages are 100% ready but many of this string still are not synchronized with Launchpad. Are they going to be synchronized before the final release? At the moment, this depends on the Ubuntu packagers and GNOME developers: GNOME developers have to release tarballs which include these translations, and Ubuntu packagers then have to package them into Ubuntu. After that happens, they get into Launchpad in a day or two, and then they appear in the next language pack update for Ubuntu. This does include many links that can break, so we in Launchpad are working on doing direct imports from upstream, thus eliminating the dependency on GNOME developers and Ubuntu packagers, and shortening the time translations get from upstream into Ubuntu (hoping it will be 1 day). This won't be available before June though, so not for Lucid. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: ubiquity-slideshow-ubuntu: contemplating some string changes
Hi Khaled, I am sorry you find this missing feature of Launchpad a deal-breaker. Here's a few explanations on what's the case with fuzzy matching, and other ways you can work-around it. У пет, 26. 03 2010. у 00:00 +0200, Khaled Hosny пише: What I can't really understand how a very simple and basic feature like marking old translation as fuzzy when merging new templates doesn't yet exist! some thing that gettext tools had years before my birth. I am sorry to hear you feel this way. gettext fuzzy matching works very well for cases like typos. Unfortunately, it also fails for anything else because it uses an algorithm based on character counting. I've seen numerous cases were translations in Ubuntu were 'approved' from incorrect fuzzy suggestions. At the same time, majority of messages in Ubuntu are short where it does more harm than good. And with long messages, it's even harder to notice wrong translation if it differs in something like not. Also, all the fuzzy flag handling stuff made code very complex and UI even more so: we had two concepts of unreviewed messages, and people never understood what's really going on. So, we did away with the fuzzy handling. I'll attach two PO small PO files which demonstrate how it's not really perfect algorithm: i.e. it recognizes winds as similar to windows. I am pretty sure most languages translate these differently. To try it out, do msgmerge windows.po new.pot and see how it works with fuzzy matching. I've seen even worse examples where the two short words might even have completely opposite and not just unrelated meanings. I'd like us to have more time to implement an excellent tool for doing similarity matching that doesn't suck. Word-based at least, but perhaps trigram (three connected words) based would be even better. We can't do it trivially because of performance considerations, but there is a clear path forward. If you have some time and skill to help us get there faster, I'd be more than happy to discuss it with you. There is only so much we can do at any given time, and as David mentioned, we are focused on getting direct upstream translation imports into Launchpad and Ubuntu. The old blueprint describing this feature is: https://blueprints.edge.launchpad.net/rosetta/+spec/rosetta-fuzzy-merge As you can see from the related bugs section there: we get bug reports about it all the time. And we've only recently came to a point where we can spend time on implementing new features (such as bazaar integration, and translations sharing between series, direct upstream import). Eventually, we'll get to this as well, and to things like glossaries, full APIs, discussions on translations and so forth. I'm really annoyed by this, my time is more valuable to waste it redoing translations over and over again. The fact that launchpad is annoying me more and more every day, that I might just abandon doing any Ubuntu translation and save my valuable time to something else. I am really sorry Launchpad causes so much waste of your time. However, apart from the workaround Gabor mentioned, there is another: download latest POT/PO file and do your merging locally using gettext tools, and you'll get exactly the same benefit msgmerge (from gettext) provides you otherwise. You'll have to go through all the fuzzy messages in an offline PO editor (like KBabel, GTranslator, POEdit...), but once you are done you can re-upload it (don't forget to strip fuzzy flags off). I don't see how this is different than what happens anywhere else (like GNOME, KDE, or anywhere else at all). It's just that Launchpad otherwise hides all the complexity so doing this step that is painful everywhere is as painful with Launchpad, instead of being simple as everything else is simple in Launchpad. But then again, I *am* biased. Cheers, Danilo msgid msgstr Project-Id-Version: test\n PO-Revision-Date: 2010-04-01\n Last-Translator: someone\n Language-Team: test\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n msgid winds msgstr msgid msgstr Project-Id-Version: test\n PO-Revision-Date: 2010-04-01\n Last-Translator: someone\n Language-Team: test\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n msgid windows msgstr translation of windows -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: rosetta language variant support
Hi Arc, У нед, 04. 10 2009. у 17:03 -0400, Arc Riley пише: So is https://answers.launchpad.net/rosetta/+faq/23 incorrect? No. This would seem to imply that language variants are supported. What do you mean with 'language variants'? Language codes using 'xx...@something' are not supported fully. You can use 'make suggestions from language' to show another language translations as suggestions (if it's not a language using above mentioned language code style). We have a team being established for a variant transliteration, is rosetta going to work for us, and if not what is the recommended solution for us until it does? Launchpad is open source (get started at https://dev.launchpad.net/), so if you are interested in getting help on integrating a feature like this into Launchpad, we'd be happy to help. Though, note that it'd involve a lot of basic infrastructure work to accommodate future variant support as well. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Ubuntu and Kubuntu templates priority
Hi Dimtry, У пет, 02. 10 2009. у 11:45 +0400, Dmitry Agafonov пише: Technically speaking tags for templates can do both. Tag some as ubuntu, some as kubuntu, and both as importance_1 to importance_9. One underlying technology and many use cases including filtering, ordering and grouping at UI level. If you want to discuss design and do the actual implementation of that approach in Launchpad, I'd be more than happy to help out :) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: [Launchpad-dev] Getting some languages over the 80% complete level
У чет, 01. 10 2009. у 12:50 +0100, Martin Albisetti пише: 2009/10/1 David Planella david.plane...@ubuntu.com: Hi Martin, El dj 01 de 10 de 2009 a les 12:03 +0100, en/na Martin Albisetti va escriure: 2009/10/1 David Planella david.plane...@ubuntu.com: This list is now available at: https://wiki.ubuntu.com/Translations/ReleaseLanguages/9.10 How about linking the languages to the page on Launchpad with the untranslated string, so eager people can just jump in and start helping? Although a good idea, unfortunately there is no such location with a link to _all_ untranslated strings in Launchpad. However, what we could do in the wiki page is to provide a link to the particular language's translatable packages, as in e.g. https://translations.edge.launchpad.net/ubuntu/karmic/+lang/es for Spanish. I'm open to any suggestions and improvements to the wiki page. We should file a bug, and get the translations team to help us have such a filter. As I told Martin, this is one of the things I want to do with distribution (and project pages). It's fine to file a bug, but with things like these (which we have quite close to the top of our minds :) it's more likely we'll file a new bug when we start work on it because we'll file bugs as we create work units as well. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: [Launchpad-users] Translations import queue stopped (again)
У пон, 14. 09 2009. у 13:20 +0200, Danilo Šegan пише: I managed to come up with a work-around for the problem. Thus, I hope we'll be using slower version only when we hit the postgres bug. We should be getting a fix up on production machines later today. For anyone into technical details, please see https://bugs.launchpad.net/rosetta/+bug/408718 Imports have been re-enabled and the import script is happily churning along. It will take around a day for it to fully catch up. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations import queue stopped (again)
У пет, 11. 09 2009. у 20:01 +0200, Danilo Šegan пише: On Monday, we'll roll out a slower version of the script out which excludes the query which causes postgres to misbehave, but that will mean that imports will go noticably slower. We will actively work on finding a solution to the problem after we get at least the basic imports back up and running. I managed to come up with a work-around for the problem. Thus, I hope we'll be using slower version only when we hit the postgres bug. We should be getting a fix up on production machines later today. For anyone into technical details, please see https://bugs.launchpad.net/rosetta/+bug/408718 Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Translations import queue stopped (again)
Hi all, Translation import queue will not be processing any entries until at least Monday evening (which is the earliest time we can get changes into Launchpad production machines). What happened? Last night a poimport script caused a problem in Launchpad database and caused overall system problems. Basically, all of Launchpad was affected. Nothing so far indicates that it is a problem with the script itself, but it seems to have pushed our postgres instance over the edge by making it eat all the disk space on database server. To preserve other services, poimport script has been stopped until we come up with adequate workaround. I know this is unfortunate and may make it impossible for you to do your work, but in order to avoid causing problems for everybody else (along with causing them for you), the script will stay disabled over the weekend. What will we do about it? On Monday, we'll roll out a slower version of the script out which excludes the query which causes postgres to misbehave, but that will mean that imports will go noticably slower. We will actively work on finding a solution to the problem after we get at least the basic imports back up and running. I thoroughly apologize for the reduced service quality. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: maltese translations
Hi Myriam, У сре, 09. 09 2009. у 10:27 +0200, Myriam Schweingruber пише: On Tue, Sep 8, 2009 at 13:17, Jonathan Aquilinaeagles051...@gmail.com wrote: is there a team at least downstream that has started working on maltese translations of packages ? For KDE, there is an upstream team, please get in touch with them here: http://l10n.kde.org/team-infos.php?teamcode=mt And please, do *not* translate *any* KDE packages in Rosetta, since there is an upstream team. All translation by KDE and Gnome are done upstream, so work in Rosetta would be redundant and we all know how bad the results end up. If there is no Ubuntu Maltese team as Adi points out, you'd do a much better job by setting one up. Then you'd be able to restrict who can edit translations. Today, if nobody works in Launchpad to translate Ubuntu specific strings, even with fully translated GNOME and KDE there will be some untranslated strings. So, one should still translate in Launchpad. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: [Launchpad-users] Imports slowness in Launchpad translations
Hi Dmitrijs, У уто, 08. 09 2009. у 20:06 +0300, Dmitrijs Ledkovs пише: Well the import queue is growing again and it's up to 53k and I haven't noticed for anything to get imported I might be wrong though. There are also items from 2007 / Gutsy. Are they really need to be imported? There is no backlog at the moment. Older files remain in the queue for no particular reason, but they should be mostly blocked. We also keep the 'blocked' entries because these are manually blocked translations (for some reason), and if we remove them we'd have to block them manually again. If you are interested in how much stuff really needs to be imported, check up on entries in the 'Approved' status (zero at the time of this email, and close to zero over the past two days). Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Imports slowness in Launchpad translations
У сре, 02. 09 2009. у 18:01 +0200, Danilo Šegan пише: We've noticed a big slowdown in how translation imports are processed. If you notice any other services seeming to go slower than usual, please let us know. We tracked down the problem: https://bugs.launchpad.net/rosetta/+bug/410293 We have a fix for it already, but it's triggered only by certain KDE package uploads where the uploader has their email set as obsolete. Imports are now going on at a much faster rate, though we do have another 37k files to process in the backlog (it grew to 55k files during the slowness). Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Degree of trust and quality for Ubuntu Localization Teams
У уто, 14. 07 2009. у 11:42 +0200, David Planella пише: That said, it is easy enough to request a list to lists.ubuntu.com, lists.launchpad.net or use an existing... Just a note, we do not allow Ubuntu-related lists on launchpad.net: Ubuntu has a dedicated mailing list server, so they should all be on lists.ubuntu.com. Also, I think one important point for a translation coordinator is to be responsive, and to make sure unreviewed suggestions are kept at a minimum. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Degree of trust and quality for Ubuntu Localization Teams
У пет, 10. 07 2009. у 14:35 +0200, Milo Casagrande пише: 2009/7/10 David Planella david.plane...@ubuntu.com: These were all suggestions, and I'm wondering whether these should be rather made requirements for new teams or new team admins/owners: * To join the ubuntu-translators mailing list * To have a local translation mailing list, preferably at lists.ubuntu.com * To have a set of translation guidelines I would also suggest that: if there already exists an upstream team for your language and they already have guidelines, use those. Same for glossary. I wouldn't require translation guidelines if there are no existing upstream teams with significant translation done (we can easily see this: are there a lot of imported translations already for the language?). We should not stop people from starting their translations efforts with Ubuntu and Launchpad, and developing guidelines as they go along. In that sense, I would differentiate these guidelines for prospective teams for established languages (established in free software translation) and new languages. Ubuntu and Launchpad still provide the best platform for kick-starting your own language translation, and we should not lose that in the process. Also, I've long suggested we link to such guidelines from Ubuntu Translators group, along with guidelines on any specifics for Ubuntu translations (i.e. Debian Installer, OpenOffice, Firefox, ...). On all other points, I completely agree. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Degree of trust and quality for Ubuntu Localization Teams
У сре, 08. 07 2009. у 07:28 +0300, Khaled Hosny пише: And some team owners don't even care about this, since, unlike many upstream teams, whoever applies for a team first get it without any attempt qualify him (compare with Gnome for example). The same is true for GNOME: first person to appear for a language gets to run the team. It's just that process for doing any translation submissions is so much more involved, that people who go through that are willing to go through the process of making sure that person is responsive. Basically, there's more of a what after process in place, but that was built over time. Hopefully, Ubuntu is getting that soon as well. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Strange position of images in translation pages
Hi Jeroen, Milo, У сре, 24. 06 2009. у 17:02 +0700, Jeroen Vermeulen пише: Milo Casagrande wrote: don't know if it has been reported as a bug on Launchpad or if it is related to me using edge, but I'm experiencing some strange images positioning in the translation overview pages. Since a picture speaks more than a thousand words, I'll attach it here. Is it something already known? I believe it's a known problem, yes. Work in progress on the generic UI side of Launchpad. FWIW, it was a minor nag with a switch to using CSS sprites for many images to improve loading time. It was fixed quickly by Martin A., but edge didn't update for a few days for some unrelated problem. All should be fine now, but if not, please let us know as soon as you spot something weird :) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Launchpad translation credits
Hi Jimmy, Evan, thanks for forwarding this. У пон, 22. 06 2009. у 12:41 -0500, Evan R. Murphy пише: 2009/6/22 Jimmy Angelakos vyr...@hellug.gr: It has come to our attention that Launchpad/Rosetta removes ALL translation credits from the .po files that are uploaded to it and replaces them with Copyright (c) 2009 Rosetta Contributors and Canonical Ltd 2009. This is clearly unacceptable, how can we remedy this situation? I agree, and that's why Launchpad doesn't do that. It actually does the exact opposite whenever possible. With that in mind, I believe there's nothing to remedy. It specifically preserves the header comment from the PO file that was initially imported, exactly for this reason. But, sometimes a PO file was *first* created in Launchpad before it ever existed upstream, and such files have this copyright notice. As for actual translation credits in messages like translator-credits or Your names (KDE credits message), we've had to automate that since people were removing upstream credits without realizing that. So, now such messages are automatically extended with clearly marked Launchpad contributors, but credits as imported from upstream remain in. Hopefully this clarifies some things. If there are any particular cases that bother you, please get in touch with me and I can look into them. Cheers, Danilo (Launchpad Translations developer) -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Launchpad Translations: re-enabling global suggestions on edge
Hi guys, For the next few days at least, I'll be re-enabling global suggestions on edge. As a reminder, global suggestions are translations you see among suggestions for a message, but from different software packages in Launchpad (you can recognize them by Used in and Suggested in markers below the translation itself). This is very important part of Launchpad, but we've been disabling them from time to time through last few months when we were worried about performance. The last time we disabled them was in late April (with our 2.2.4 release), when we rolled out big part of our message sharing code (more on that later, once we polish it further :). I want to get a few days of testing on edge, so we can decide whether we can re-enable them with our 2.2.5 release coming later in May. Note that they can't cause saving problems you experienced with the previous timeout problem on edge, so while you might see slower loading pages, you should get more useful suggestions and will help us in making sure this feature works correctly for everybody so we can re-enable it everywhere. We will be closely monitoring timeouts to see how is it affecting translators, and if it's a big problem, we'll shut them down until we are certain they work well. Thanks for your patience and help in making Launchpad Translations rock. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: [Launchpad-users] Timeouts on translations.edge.launchpad.net
Hi all, У пон, 11. 05 2009. у 13:02 +0200, Danilo Šegan пише: A recent bug fix has caused performance problems when updating statistics for PO files with every save on translations.edge.launchpad.net (since very early on Saturday). I believe this problem to be resolved on edge now. If anyone hits any more problems, please let me know. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Timeouts on translations.edge.launchpad.net
Hi all, A recent bug fix has caused performance problems when updating statistics for PO files with every save on translations.edge.launchpad.net (since very early on Saturday). This is now recorded as bug 374826, and I'll work on it later today, but please refrain from using edge for your important work during that time, and instead make use of stable https://translations.launchpad.net (on that page, you can temporarily disable redirection for 2h). I apologize to all who lost their important work due to this, and I thank everybody who's been patient with using our bleeding edge server and helping us catch problems like these early. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Improving Kubuntu's translations
Hi Harald, У пон, 04. 05 2009. у 11:33 +0200, Harald Sitter пише: Within the last couple of days we, at Kubuntu, have been working out a list of major issues we are facing with the current translation process. They are of considerable impact since I know quite some people who actually decided to not translate Kubuntu any longer, or even stopped using it. But not only users are affected, I think if we continue to ship Kubuntu with such poor quality we will also see a decrease in contributors as well. Why would somone who lives in France, spend his spare time on Kubuntu when he can't even make his mom or brother use it because they wouldn't understand half the system. Thanks for writing to the list. And sorry for not responding earlier. First off I'd like to direct your attention to http://www.flickr.com/photos/19616...@n00/sets/72157608562200171/ Which provides a set of pictures documenting the state of translation in Kubuntu and openSUSE, starting with 8.04. It especially gives a quite good impression of what is going on in-development and how the end result relates to that. Now, I know that especially for language packs there is a certain need for short-term breakage, however it happens way too often for Kubuntu (and I would suppose Ubuntu as well). This prevents sensible QA as well as using the product. Actually, Ubuntu is never as badly affected as Kubuntu: KDE uses completely different set up of translations, and especially KDE4 introduced a huge number of changes to the layout of templates. They were all changes that neither Launchpad nor language pack infrastructure were ready to handle. This is not only about majority of Ubuntu/Launchpad developers being GNOME-oriented (though, that plays a part too): KDE uses different l10n layout compared to most other free software. One of the most incredible things that happened in the 9.04 cycle were, that the pkgbinarymangler (i.e. the component that is responsible for stripping translations from packages, in favor of the ubuntu language packs) was changed to remove translations from desktop files. Incredible is that no one told the Kubuntu devs beforehand, that no one even tested if that change would cause problems, that this change was done less than a month before release. Such things just can not happen anymore. Personally, I don't like the .desktop hack that Ubuntu uses for GNOME either: it's only a half-solution, and I believe more effort should be spent on providing a full solution for regenerated content translation via language packs. However, that would require a lot more time to achieve. If this was done only a month before release, that sounds terribly bad, though. In general, Kubuntu l10n suffers from lack of testing (or maybe bug reporting?) early in the development cycle, but introducing a change a month before release is definitely bad. :( It is this and a lot of smaller regressions that drain Kubuntu's development performance (change all of upstream KDE's langauge packs to include the proper desktop file .pots is certainly no fun and not done within a couple of minutes). So here comes the list of issues: http://docs.google.com/Doc?id=ajk6csn6c2vn_0c6d8rp6w I'll try to address some of the issues here that I believe are important: * Upstream * Make it easy to get from Rosetta to the upstream Po/Pot files (i.e. include links to websvn.kde.org ) At the moment, each POT file in Launchpad can have an arbitrary description. Links are not highlighted there atm, but we can easily fix that and promote its use more. Still, this would have to be manually maintained since it's not something that can be easily automated. Also, we'd like to have a read only copy updated daily of all upstream translations in Launchpad, to be able to offer them as suggestions across the system. Our recent work on Bazaar integration is a step in that direction as well. * Translations can only be changed if their original strings were altered by a patch or when there is sufficient evidence that the change is necessary. Apart from technical difficulties in achieving this, I wouldn't like to do this because it's also the wrong thing to do (IMHO, at least). Updates to translations in Ubuntu can happen even after upstream (i.e. KDE) stops releasing updates for that package. Also, I don't see why we should stop people from using Launchpad merely as a web-based collaborative PO editor to translate anything in Ubuntu, including KDE, and then submit those PO files upstream. * Make it easy to push changes upstream. We try to do that as much as possible; as you rightly note, nobody would accept direct commits from Launchpad, and I am pretty sure upstream translation teams would accuse us of spamming if we started emailing them with every few changes on a translation. So, at this moment, we do the best we can: we offer easy download of partial PO files which give you only what
Re: Translation status for Ubuntu Start Page
Hi Adi, У пет, 17. 04 2009. у 11:33 +0300, Adi Roiban пише: I tried to used the automatic Rosetta import feature release this cycle, but it looks like it's not ready yet... so I went back to manual import. Template import should be fine. You should not need to do any other imports of actual PO files after that (other than the initial one, if you want). We've accidentally landed a UI change which enables PO imports as well, and that's what you used which is not yet ready on our production servers. Cheers, Danilo -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. LTCSERVER -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations have become suggestions
Hi Moritz, У пет, 17. 04 2009. у 13:23 +0200, Moritz Baumann пише: during the translation process of Jaunty I've experienced a weird behaviour multiple times: Rosetta suddenly degraded my translations to suggestions some hours after I've made them. Two examples: - - computer-janitor - - new upstream translations for gnome-user-docs (uploaded by me for completing the translation in launchpad) That really sounds strange. Can you give URLs to actual pages where you see that happen, describing a situation in a bit more detail. Cheers, Danilo -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. LTCSERVER -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: update ubuntu-docs errors
У чет, 09. 04 2009. у 10:01 +0200, Alexey Balmashnov пише: Yep, there is one error reported on the page against ru, namely hardware template. The problem is: I went to a rosetta, downloaded file, checked it and it validates just OK. Note that gettext cannot catch these errors (if it could, Launchpad would too). This is usually manifested only with unhelpful error messages from xml2po when building a package. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: gfxboot-theme-ubuntu
Hi Milo, Colin, У пет, 03. 04 2009. у 11:54 +0200, Milo Casagrande пише: Colin Watson ha scritto: Actually, in this case it's better to ask the guy responsible for gfxboot-theme-ubuntu, i.e. me. Emmet Hikory did this in https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/354364. I've added these strings, although I don't know whether there'll be time to translate them. Wouldn't it be possible to manually push or accelerate the import of the new template in Launchpad for this and also for debian-installer as there are new strings there too? Sure. Arne or Adi need to approve the templates (like bootloader.pot which seems to be waiting for manual approval[1]) and they'll be imported (fwiw, our import queue is working quite well these days, so they should be imported in a few hours once they are approved). But, note that depending on how these strings are integrated (i.e. I suspect they are not using language packs), you've got only non-langpack translation deadline (April 9th) to translate them. Cheers, Danilo [1]https://translations.edge.launchpad.net/ubuntu/jaunty/+source/gfxboot-theme-ubuntu/+imports?field.filter_status=NEEDS_REVIEWfield.filter_extension=pot -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Ubuntu Translations Coordinator
Hi David, У чет, 02. 04 2009. у 13:39 +0200, David Planella пише: as announced by Jono on his blog [1] (and now on my brand new one as well ;) [2]), I'll be joining Canonical as the Ubuntu Translations Coordinator on Monday the 6th of April (next week), so I simply wanted to send a brief introductory message before starting in full swing on Monday. Welcome to your new role. I am very happy to see you around, and I look forward to working with you :) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Launchpad doesn't save string with less spaces
У уто, 17. 03 2009. у 09:46 +0100, henn...@ubuntu.com пише: Am 16.03.2009 23:09, Igor schrieb: I need to replace 6 spaces in translated string to 1 space in order to make it fit in columns. This probably is a bug in the source code of coreutils, I would say. Why is it not using printf formating to make table columns? Think about filing a bug there. But unfortunately launchpad doesn't save string with reduced number of spaces. This may actually be a feature to make sure that no space is forgotten ... ;) But you could file a bug about it (or search if one already exists): https://bugs.launchpad.net/rosetta https://bugs.edge.launchpad.net/rosetta/+bug/30358 Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Ubuntu Docs Jaunty PO to XML errors, HTML files
Hi guys, У уто, 17. 03 2009. у 00:07 +0100, Alexey Balmashnov пише: On Mon, Mar 16, 2009 at 8:58 PM, Adi Roiban a...@roiban.ro wrote: Hi, On Mon, 2009-03-16 at 20:31 +0100, Alexey Balmashnov wrote: Nice, looks like exactly the same errors as ones that had been fixed a while back for Intrepid. Are there any chances that tool validating somehow results of translators work will be merged into Rosetta? Or may be used as an intermediate step somewhere in the import process for translations of the current+1 release? Basicaly I was just converting back from po to xml and the from xml to html. I don't think we will have those validations in Rosetta, as Rosetta is supposed to work with PO files... and there is a long feature list waiting. Which is not a blocker. See below. Aha. Then one more point in the feature list won't make it longer anymore, so why not to add this? This can best be done directly in GNU gettext (to allow xml-format format specifier) and xml2po and/or intltool. Once GNU gettext is able to check well-formed-ness of XML messages, I'd be happy to accept patches to both xml2po and/or intltool, and depending on the available time, I might even write them myself. And as soon as the upstream stack (GNU gettext, xml2po) supports such xml-format tag, Rosetta will support it as well. If I find time (read: unlikely), I'd be happy to extend GNU gettext to support xml-format as well, but if one wants to see that happen, they should not count on me. Basically, msgfmt -cv should be able to catch most of the problems like these. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Problems and suggestions in Launchpad translations (rosseta)
Hi Adi, У чет, 26. 02 2009. у 19:53 +0200, Adi Roiban пише: I don't have a general answer, but for example for GNOME, all GNOME packages could be taged and be availalbe for translation in Ubuntu, only after the GNOME release, with a BIG note telling translators why they can not translate GNOME in LP right now and a guide to help them join the uptream project. That's not the answer. It entirely depends on the translation team. If GNOME upstream team wants to use Launchpad as a *tool* to the translation and then download PO files and submit them upstream, why should we stop them? The solution is to enable per-language team choice which would be per package, but you can imagine how that's not trivial to do :) Well in Launchpad you can translate upstream projects , and each upstream project can choose if it want to use launchpad for translation. Right now each project is free to import it's trunck branch into Launchpad. GNOME is free to import the trunk branch in LP, but this action depends on the upstream will :) Not really, if we communicate everything well, we can have parallel team structure in Launchpad for those that are interested in using LP as a translation tool: I still believe it's the best tool to do translation maintenance, and as soon as we get bazaar support in, I'd like us to start including upstream trunk translations. However, in those cases we'd strictly enforce that such projects use proper translation group (like gnome-translators) and we'd only allow actual upstream translation coordinators to run team in it. Talk to the GNOME Greek translators and see if they are willing to import trunk in LP. But this should not stop GNOME Romanian (hypothetically) translators from using Launchpad as a tool and getting their PO files in an easy way and submitting them themselves (or, once we get APIs, writing tools to submit them directly to upstream source code repositories or translation frameworks like the one GNOME has now). We just didn't set any of this up yet because we don't want to manually sync translations for all possible upstreams. There are discussions about creating such a glossary in Launchpad, but I think that for now the main goal on LP is to prepare the project to be free software. There are other priorities, but the simple approach for Glossary I wanted won't really work. Which means we'd have to develop a full glossary, which means a lot more work. For Ubuntu it's easy... just look at the needs review column. In addition I have created this webpages: http://l10n.ubuntu.tla.ro/ubuntu-translators-review/el.html http://l10n.ubuntu.tla.ro/jaunty-l10n-status/el.html I know they are not officials , but it's a starting point. These pages are excellent: we are having a UI sprint next week, and I'll make sure we plan how to solve this problem by integrating necessary features inside Launchpad. Thanks for taking the time to do them, I believe they are really helpful for everybody until we get Launchpad to play nicer about this stuff :) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Problems and suggestions in Launchpad translations (rosseta)
Hi Kainourgiakis Giorgos, Thank you for sharing your notes. У сре, 25. 02 2009. у 09:52 +, Kainourgiakis Giorgos пише: Hello all, I wrote these notes because of this: https://wiki.ubuntu.com/UDSJaunty/Report/Community. In UDS 2009 the following topics, Make Rosetta attractive for upstreams and Launchpad Translations left blank. I have no idea if the suggestions are techinaly viable, but here they are. I've seen this email, updated that wiki page with my report from UDS, but forgot to reply here with the link[1]: thanks to Adi who corrected me. We are basically aware of majority of the problems you cite, and we've been working on different solutions over time. Unfortunately, there's a lot of work, but I think we have hugely improved during the last few years in all the areas you mention. And we'll continue improving until Launchpad Translations is the best translations tool you can get. But, we are not there yet! :) Cheers, Danilo [1] https://dev.launchpad.net/Translations/Reports/UDSJaunty -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: voting on a string
Hi Kenneth, У нед, 01. 02 2009. у 01:56 +0100, Kenneth Nielsen пише: Changed the spelling error in the title so that it now is sign-off the way it should be, that means that it is now to new URL's https://blueprints.launchpad.net/rosetta/+spec/sign-off-on-translation https://wiki.ubuntu.com/SignOffOnTranslation Thanks for filing these and explaining it in this many details. I believe I am sort-of-aware of what it is that you are proposing here. As we discussed previously, I don't like the idea too much: it is about introducing another layer for people to submit something (without it ever being looked at, which is a likely to happen). Simply, our current reviewing mechanisms are not being used to an enough extent to warrant introducing another layer in between. And, there's still a lot we can do to improve the current reviewing workflow so it's more usable without introducing more complications. And you might be surprised, but implementing feedback and commenting system would be easier than actually doing this (and a better solution to the problem, imo) — this is actually what makes me not like the proposed solution. I.e. if you came up with something that would be simpler to implement and obviously more useful (this one might be more useful than having a commenting system, but it's not too obvious), I'd be happy to have us consider working on it sooner rather than later. :) Of course, once we come to start discussing implementing this, we'll consider your proposal as well. So, maybe I just don't see all the benefits of the proposed solution yet, and will see them as the time comes. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: How to revert to upstream translations
Hi Milo, У уто, 20. 01 2009. у 02:42 -0700, Milo Casagrande пише: Following on what you said on the previous mail, probably the Packaged term could lead to some misunderstanding. IMHO, probably, we are more accustomed to usptream and downstream kind of terms. Just a suggestion: would it be possible to change that definition to Upstream instead of Packaged and with the glossary blueprint [1] we discussed at UDS insert the term Upstream in the glossary and link it? Or at least, if changing the term is not feasible, would it be possible to link Packaged using the glossary thing? Not really. Upstream is a confusing term, especially when used in the Launchpad context (Launchpad uses upstream to also indicate projects which are directly hosted in Launchpad). Apart from that, it's not even correct (Ubuntu package might not exactly match upstream). We've thought about how to best name this, and never came up with the better name. The other best alternative we came up with was Imported, but we figured that was going to confuse more people if displayed in the UI (i.e. was that stuff that was imported that I uploaded, or imported from the package/upstream). Cheers, Danilo -- 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 Marcos, У суб, 17. 01 2009. у 16:31 +0100, Marcos пише: 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. Firefox PO files (as exported by Launchpad) are special PO files only used for building XPI files, and are not usable for any other uses (unfortunately). There is no use in checking them with msgfmt -cv. 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 I am not sure exactly what you are doing, so if you want Launchpad Translations team to investigate, please ask a question on https://answers.launchpad.net/rosetta with all the details (including what particular PO file and what is causing you problems). Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: How to revert to upstream translations
Hi Og, others, У нед, 18. 01 2009. у 15:10 -0500, Og Maciel пише: On Sun, Jan 18, 2009 at 2:31 PM, Milo Casagrande m...@casagrande.name wrote: Il giorno dom, 18/01/2009 alle 19.54 +0100, Åsmund Skjæveland ha scritto: Some strings in Launchpad have better translations upstream than in Launchpad. If I replace the Launchpad translation with the upstream string, will Launchpad automatically detect that the upstream translation takes over? Yes... For the record, this is new to the translation process via Rosetta, and as far as I know will be used for the very first time. How well it will be used is still to be seen. I am however hoping for the best. Actually, this has been in for over a year. Looking at [1], I'd say exactly since 2007-06-08, and 1.1.6 release (June 2007). And to confirm Milo's statement, yes, that's exactly how this will work. Packaged is whatever is coming from an Ubuntu package (i.e. for most purposes when there are no significant patches in Ubuntu, the same as upstream), not what was in the last language pack. Cheers, Danilo [1] https://bugs.launchpad.net/rosetta/+bug/32471 -- 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 Milan, У суб, 17. 01 2009. у 14:18 +0100, Milan Bouchet-Valat пише: 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. Launchpad problems are only a (very small) part of the picture here, and Translations team is fixing those already. They could happen only in a very awkward set of events described in bug 317578. As others have noted, a lot of these are actually potential upstream problems, and this analysis should help you detect them and fix them. If you do the right thing and fix them both upstream and in Launchpad, every other distribution would benefit as well. Cheers, Danilo -- 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
Hi Bruno, У суб, 17. 01 2009. у 12:33 +0100, Bruno Patri пише: 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. IMO, this is a good chance for you to contribute something useful to upstream translations. 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. Indeed. This is one of 'false positives' so no need to worry about it. AFAIK, the search was really done by '%' sign. 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 ? If this particular application uses above string in the form of fprintf(file, _(Sets the tone... 75 percent...)); introducing % would make the fprintf call see % e (space-padded %e specifier) which would make fprintf look for a floating point number as the next argument on the stack. Though, you should note that problems like these are application bugs, and should be reported as such. However, you can't tell unless you dive into code for the application itself. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: How to revert to upstream translations
У пон, 19. 01 2009. у 08:00 -0500, Og Maciel пише: On Mon, Jan 19, 2009 at 6:06 AM, Danilo Šegan dan...@canonical.com wrote: For the record, this is new to the translation process via Rosetta, and as far as I know will be used for the very first time. How well it will be used is still to be seen. I am however hoping for the best. Actually, this has been in for over a year. Looking at [1], I'd say exactly since 2007-06-08, and 1.1.6 release (June 2007). Right, but the real problem happens when someone decides to change something that came from upstream (case 1) OR adds a new translation for a string that had none (case 2). The next time Rosetta imports translations from upstream, it will no longer track these two cases, Case 1 has been correctly tracked for a long time (i.e. forever, or at least since I've been around: i.e. if you revert to the packaged translation by using the same string, Launchpad would continue to prefer updates from the package). Case 2 has been made automatic recently (December 2008). What I talked about was UI that helped detect both cases which has been around for a little less time. Cheers, Danilo -- 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.
У чет, 15. 01 2009. у 22:09 -0500, Og Maciel пише: I have always thought that Rosetta validated the strings before saving them. Is this a regression or was this data brought in via different means (also with no validation)? This can happen if upstream didn't introduce c-format flag right away. Rosetta doesn't recheck all the translations once c-format flag is added, which I filed as https://bugs.launchpad.net/rosetta/+bug/317578 Also, Ubuntu team wants to fix problems that are unknown even to upstreams (i.e. translations using %-formatting where strings are not even marked as c-format). Basically, this means fixing problems for all upstream projects, and my suggestion would be for everybody involved to file specific bugs so this can be fixed upstream as well. Cheers, Danilo -- 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 Milo, У пет, 16. 01 2009. у 01:46 -0700, Milo Casagrande пише: Original Message Subject: Re: HEADS-UP! URGENT! Major problem with translations for Hardy and Intrepid. From: Henning Eggers henning.egg...@canonical.com Date: Fri, January 16, 2009 9:21 am No, I'd expect it to be the line number in the po file. I imagined that but that's not going to be easy anyway... Just another example: subversion for my own language. Looks like there's one string broken. Nobody of our team has ever touched that package, the translation has been like that since 2006. Downloaded it, tested it, no errors. One should note that Ubuntu team compiled a list which likely includes a lot of false positives. It's impossible to cover all potential problematic cases (i.e. messages which don't have c-format set, but might need to) without getting a bunch of cases which are not really a problem (is % something a sprintf string or not)? I should point out that helping with this analysis will benefit all upstream translations and programs as well, since I expect everybody to submit improvements upstream as well. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Launchpad Translations 2.1.12: Change in translation precedence policy
Hi all, Launchpad Translations has changed the translation precedence policy with the December release: now upstream (packaged) translations will be given more priority in specific cases. Yet, Launchpad Translations keeps the ability to override any specific upstream translation if so is desired. This mostly concerns Ubuntu and it's upstreams (packages), though it will have a small effect on projects hosting their translations in Launchpad as well. If you understand better with examples, just look at the examples section below. == Ubuntu == This should be the final solution that will make sync from Ubuntu's upstream translations (contained in packages, thus also called packaged) Do The Right Thing. When a translation has been (inadvertently) modified before a packaged translation was imported, when packaged translation actually comes in, it will be set as the active one. However, if there was already a packaged translation, translators working on Ubuntu translations in Launchpad will be able to override it, and when a new packaged translation comes in, it won't be set active unless Ubuntu translator decides to do that. This should solve the most common problem of diverging translations between Ubuntu and it's upstreams: they are done accidentally (i.e. done in Launchpad before upstreams have even started their work on translations). Now, we can concentrate on providing better tools for sending fixes/improvements done in Launchpad upstream. This is not a perfect solution, and still means duplicate, unnecessary work. To further alleviate that, we'll work on providing more frequent sync with upstreams in the future, but there's a lot of hard work involved. Note that all of this happens on a single message level basis. === Recommended convergence path === To converge all Ubuntu's and it's upstreams translations, this is the procedure we recommend. 1. Go through all the Ubuntu packages for your language, and look for changed in Launchpad messages (you can see the count in Changed column on language overview pages like https://translations.launchpad.net/ubuntu/intrepid/+lang/sr — clicking on the number there will take you directly to just those messages, and you can easily revert by choosing a Packaged translation). You have to be a reviewer for your language to do this (i.e. member of Ubuntu translations team for the language). 2. For any changed translations that you keep, we suggest you submit them upstream so they benefit from your work as well. 3. If 1. involves too much work, we can arrange for automatically reverting all translations in Ubuntu for a particular language. To discuss that (because it's hardly the best thing to lose all potential fixes and improvements), please file a question on https://answers.launchpad.net/rosetta/ 4. Keep submitting fixes/improvements you make upstream: during course of your work on Ubuntu translations, you'll find more problems and you'll fix them. For your translation to hit other distributions, you should submit them upstream. === Examples === To illustrate when upstream translations have precedence, here's an example: 1. GNOME Panel, message _Open, untranslated 2. Ubuntu GNOME Panel message for _Open is untranslated 3. Someone translates Ubuntu message in Launchpad to _Foo 4. Upstream translates _Open to _Bar 5. When new upstream translation arrives, Launchpad makes _Bar active over _Foo (making _Foo a suggestion) Example case where Launchpad translation takes precedence is: 1. GNOME Panel, message _Open, translated to Foow 2. Ubuntu GNOME Panel translation for _Open is imported and is now Foow 3. Someone fixes translation in Ubuntu to _Foo 4. Upstream changes translation for _Open to Foo 5. When new upstream translation arrives, Launchpad keeps _Foo active over upstream's Foo Now, ideally, Ubuntu translators will forward fixes upstream as well, so a new upstream translation matching _Foo would actually come from upstream, the two will be matched, and Ubuntu would continue using the upstream translation from then on (even if it changes: that's the logic that Launchpad Translations already has). == Launchpad hosted projects == For projects doing their translations in Launchpad, it will all behave just like for Ubuntu, but packaged translations term can replaced by translations uploaded by project maintainers (later, through bzr sync as well). Since it's a general procedure for maintainers to only do an initial upload of translations, and only regularly upload new templates (POT files), this should not affect anyone. Those having multiple sources of translations (i.e. someone committing translations directly to their source code repository) would be able to benefit from the same improvement as Ubuntu translators will. For any questions, feel free to email me or ask on https://answers.launchpad.net/rosetta Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com
Re: Renaming of a team
Hi Milo, Adi, I'll let Adi add this team as the one in charge Italian translations in Launchpad Translators group. Adi, to get more practice with your responsibility now :), please go to https://translations.edge.launchpad.net/+groups/launchpad-translators/ and use Appoint translation team or supervisor to set Milo's lp-l10n-it team as the translation team for Italian (renaming the team later won't be a problem, Launchpad is smart about it :). In general, our procedure should be to first make sure the team owner is a responsible and current translator for a language, but with Milo, that's easy :) У пон, 24. 11 2008. у 08:17 -0700, Milo Casagrande пише: I would like to ask if it's possible to rename it in: launchpad-l10n-it We might want to reconsider this and make the actual policy to be to create a team named lp-l10n-xx because that doesn't require us to change anything in Launchpad. Anyway, I was going to prepare a few policy proposals to discuss in UDS, and these might be some of them. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: R: Translation of Ubuntu glossary and terminology in rosetta
Hi Milo, Adi, У сре, 19. 11 2008. у 10:35 +, Milo Casagrande пише: --- Mer 19/11/08, Adi Roiban [EMAIL PROTECTED] ha scritto: What do you think about having the Ubuntu Glossary translated in Rosetta? https://help.ubuntu.com/community/Glossary I think that's a pretty good idea. If it's translated in Launchpad, we can do all sort of smart things with it (like linkify words in English strings to their translations from the glossary). As another matter I would like to see an Ubuntu Terminology file available for translations in Rosetta, following the idea of MS Terminology Translation: http://www.microsoft.com/globaldev/tools/MILSGlossary.mspx This file should help translators, for both documentation and applications. This is a little bit different from the previous one. From my experience with upstream translation teams, it's not always that easy to reach an agreement (inside a team) on the translation of common terms. For the Ubuntu Italian team we have a glossary based on the one from the TP project, it's not as big as the Microsoft one, but it serves our needs. For starters, I'd like to mention that GNOME did use to have a glossary: http://svn.gnome.org/viewvc/gnome-i18n/trunk/glossary/ However, I believe it was too big and too verbose to be actually useful. What we want is probably a mix of common phrases and terminology in one place, and a glossary in another. Eg. msgctxt Menu msgid Edit could be translated differently from the Edit button (i.e. you might have a style guide that recommends using imperative form in top-level menus). This would be useful to define a definite standard translation for a particular type of entry, and we should maintain it in Launchpad. This could then be used to evaluate somebody's translation capabilities to a language as well, before you accept them into a reviewer team (this is actually one of Mark's old ideas). A glossary would be a descriptive standard that explains the terms and is not as helpful in translation. Though, I'd like this to not be Ubuntu-specific, but to make it Launchpad-wide so it could be shared with all the other projects hosted in Launchpad. I too would like to see such a glossary for Ubuntu, and also for other translation projects; at least having it in English, translating it is another aspect to deal with (and probably not an easy one), but if we can create such a file, that would be just great! If there are enough interested parties, I'd like to start a project where we would develop both a common-phrases.pot and glossary.pot, if that sounds sane. However, I'd expect that you guys would be willing to help with that as well :) I would then also be happy to spend time linking these in Launchpad to translation interface, but we first need to have something in place. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Important Launchpad news: removal of non-BSD licenced translations
Hi all, У сре, 12. 11 2008. у 18:21 +0100, Danilo Šegan пише: Hello, Removing non-BSD licensed translations from Launchpad -- On Tuesday, November 18th at around 14.00 UTC we are going to We've moved the removal to right after the Launchpad 2.1.11 rollout due to some internal issues. That means it will likely be done late tomorrow (November 19th) or early on November 20th. remove all the translations made in Launchpad by people who have chosen not to relicense their translations under the BSD license. There's more about why we now require that translations are licensed under the BSD here: https://help.launchpad.net/Translations/LicensingFAQ If you have previously disagreed with license terms, you may have seent hat you can no longer edit translations in Launchpad. Instead you get read-only access. Once we remove the translations made by people who have explicitly disagreed with the licensing change, all Launchpad-provided translations will be available to share and re-use in the maximum number of other projects. Upstream translations appearing in suggestions are clearly marked with warning icons explaining how you can determine if a translation is legally reusable or not. They are not affected by the removal. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Important Launchpad news: removal of non-BSD licenced translations
Hello, Removing non-BSD licensed translations from Launchpad -- On Tuesday, November 18th at around 14.00 UTC we are going to remove all the translations made in Launchpad by people who have chosen not to relicense their translations under the BSD license. There's more about why we now require that translations are licensed under the BSD here: https://help.launchpad.net/Translations/LicensingFAQ If you have previously disagreed with license terms, you may have seent hat you can no longer edit translations in Launchpad. Instead you get read-only access. Once we remove the translations made by people who have explicitly disagreed with the licensing change, all Launchpad-provided translations will be available to share and re-use in the maximum number of other projects. Upstream translations appearing in suggestions are clearly marked with warning icons explaining how you can determine if a translation is legally reusable or not. They are not affected by the removal. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: A new language pack and limited access to translations
All, У чет, 06. 11 2008. у 17:00 +0100, Danilo Šegan пише: * Intrepid translation will be disabled on the 7th November from 14.00 UTC until roughly 15.30 UTC. This has been done, and translations are re-enabled. * We're also rolling a new language pack tomorrow so please make any urgent fixes before 14.00 UTC on the 7th November. We are expecting this to start running at 22.00 UTC, so there's still time for fixes. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
A new language pack and limited access to translations
Hi all, New Intrepid language pack and some translation down-time 7th Nov - Two important bits of news: * Intrepid translation will be disabled on the 7th November from 14.00 UTC until roughly 15.30 UTC. * We're also rolling a new language pack tomorrow so please make any urgent fixes before 14.00 UTC on the 7th November. The Intrepid translation down-time is to let us copy translations made in Hardy since we opened Intrepid translation. The new language pack is to fix a number of KDE4 translation issues. Full details are in this bug report: https://bugs.launchpad.net/rosetta/+bug/292473 Any questions? Please mail me. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: A new language pack and limited access to translations
Hi Henrique, У чет, 06. 11 2008. у 14:15 -0200, Henrique P Machado пише: Danilo, how about upstreams? We are not importing translations directly from upstreams. They come to Launchpad through package uploads. This means that we import whatever Ubuntu packagers throw at us. I'm working on the GNOME's 2.24.1 translations into pt_BR and intend to upstream them ASAP. If I send all the translations up to 13.00 UTC it will be included in the new pack? No, not at this time. There were big problems with KDE4 translations in initial Intrepid release, and this is basically an urgent fix for them. Regular language pack update should come in less than a month which will likely include your updated translations if they get released as tarballs and packaged in Ubuntu. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: renaming ubuntu-translators to launchpad-translators
Hi Adi, У нед, 26. 10 2008. у 09:48 +0200, Adi Roiban пише: As the coordinator of Romanian Ubuntu Localization I am happy to see the team growing and team members start working at translating the Ubuntu distribution but also other non-Ubuntu related projects from Launchpad. My goal for the Romanian Ubuntu Localization team is to build it as a group of people with good localization skils and any new or existent project from Launchpad (or from somewhere else) will trust it's member and rest assured that their project localization for Romanian on good hands. It's a very noble goal :) Even thou we are not translating only Ubuntu the Romanian team has Ubuntu in it's name and in some cases this stop people from joining the team of doing localizations for other projects. My sugestion is to rename the ubuntu-l10n-ro team to launchpad-l10n-ro or any other generic name. There are different ways to achieve this. For example, you may create a launchpad-l10n-ro team and include ubuntu-l10n-ro team in it, with direct memberships only to those not interested in working on Ubuntu. So, you'd basically have launchpad-l10n-ro: Romanian Translation Team - ubuntu-l10n-ro: Ubuntu translators - someone else 1 - someone else 2 ... Also if for example (just hypothetical) Fedora Project would like to translate Fedora distribution using Launchpad (when it will be free software) I doubt they will be happy to assign the localization to Ubuntu Translators groups but maybe they are ok with assigning to Launchpad Translators. Actually, they are likely to want to have their own fedora-l10n-ro which you might want to include in launchpad-l10n-ro instead. At least in my opinion. I see this change in naming as a sign that we are not a group of separatists willing to translate any Ubuntu package into our languages but we are an open group interested in translating any project using Rosetta. That's true. But, I feel there is nothing wrong with this, as long as the Ubuntu translator groups has enough credibility. And actually, if we want to go with creating actually trusted Launchpad translation groups, we should do it separately from Ubuntu. In general, they would include Ubuntu translation groups, but not always. They could also include teams of eg. upstream GNOME translators, and similar. I see this change as a mandatory one by the time Launchpad will be a free software project. There is a lot of sense in organizing Launchpad translations groups. However, I believe this is orthogonal to Ubuntu translation effort and their organization. I.e. we still want to have them as separate teams, if only because of being able to separate who's involved in Ubuntu and who isn't. I like Launchpad because people work together in the same place, the bugs and translations can be shared between projects. If we will have a Launchpad instance for each project then Launchpad will be no longer useful. Yeah, but teams can be included as subteams inside other teams, and I believe we should make use of this flexibility. Having strong and active localizations team, willing to translate not only Ubuntu but any other package will be a good reason for people to register their project on Launchpad. What do you think? I agree. So, what do you think about having Launchpad team which was separate from Ubuntu teams, but could, of course, include Ubuntu translators as well? And considering how much you've been helping with Translations for a while already (thanks!), I am wondering if you'd be willing to help run that team? (it's all only discussion right now, but I find it an appealing idea) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: renaming ubuntu-translators to launchpad-translators
Hi Adi, У нед, 26. 10 2008. у 09:48 +0200, Adi Roiban пише: As the coordinator of Romanian Ubuntu Localization I am happy to see the team growing and team members start working at translating the Ubuntu distribution but also other non-Ubuntu related projects from Launchpad. My goal for the Romanian Ubuntu Localization team is to build it as a group of people with good localization skils and any new or existent project from Launchpad (or from somewhere else) will trust it's member and rest assured that their project localization for Romanian on good hands. It's a very noble goal :) Even thou we are not translating only Ubuntu the Romanian team has Ubuntu in it's name and in some cases this stop people from joining the team of doing localizations for other projects. My sugestion is to rename the ubuntu-l10n-ro team to launchpad-l10n-ro or any other generic name. There are different ways to achieve this. For example, you may create a launchpad-l10n-ro team and include ubuntu-l10n-ro team in it, with direct memberships only to those not interested in working on Ubuntu. So, you'd basically have launchpad-l10n-ro: Romanian Translation Team - ubuntu-l10n-ro: Ubuntu translators - someone else 1 - someone else 2 ... Also if for example (just hypothetical) Fedora Project would like to translate Fedora distribution using Launchpad (when it will be free software) I doubt they will be happy to assign the localization to Ubuntu Translators groups but maybe they are ok with assigning to Launchpad Translators. Actually, they are likely to want to have their own fedora-l10n-ro which you might want to include in launchpad-l10n-ro instead. At least in my opinion. I see this change in naming as a sign that we are not a group of separatists willing to translate any Ubuntu package into our languages but we are an open group interested in translating any project using Rosetta. That's true. But, I feel there is nothing wrong with this, as long as the Ubuntu translator groups has enough credibility. And actually, if we want to go with creating actually trusted Launchpad translation groups, we should do it separately from Ubuntu. In general, they would include Ubuntu translation groups, but not always. They could also include teams of eg. upstream GNOME translators, and similar. I see this change as a mandatory one by the time Launchpad will be a free software project. There is a lot of sense in organizing Launchpad translations groups. However, I believe this is orthogonal to Ubuntu translation effort and their organization. I.e. we still want to have them as separate teams, if only because of being able to separate who's involved in Ubuntu and who isn't. I like Launchpad because people work together in the same place, the bugs and translations can be shared between projects. If we will have a Launchpad instance for each project then Launchpad will be no longer useful. Yeah, but teams can be included as subteams inside other teams, and I believe we should make use of this flexibility. Having strong and active localizations team, willing to translate not only Ubuntu but any other package will be a good reason for people to register their project on Launchpad. What do you think? I agree. So, what do you think about having Launchpad team which was separate from Ubuntu teams, but could, of course, include Ubuntu translators as well? And considering how much you've been helping with Translations for a while already (thanks!), I am wondering if you'd be willing to help run that team? (it's all only discussion right now, but I find it an appealing idea) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: New modules for Intrepid?
Hi Milo, У пон, 13. 10 2008. у 21:35 +0200, Milo Casagrande пише: I found out these new packages in Intrepid: http://tinyurl.com/3maxyy Apart from the first one that's the usual application, the other four are all docs. Do somebody know something more about that? Will Launchpad handle those translations? They were approved by mistake: I am sorry about that. I have disabled them (yesterday). Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: desktop-* from KDE4 not imported automatically
Hi Timo, У чет, 16. 10 2008. у 16:26 +0300, Timo Jyrinki пише: Just FYI. I'm not sure if they even come in some source tarball or not, or is it a special case that should be done manually (by Rosetta developers)? We've never handled cases like this. In the upstream translation stats, they are available under each module separately, like http://i18n.kde.org/stats/gui/stable-kde4/team/fi/kdebase/ (desktop_kdebase.po) There's obviously still some confusion on what KDE4 templates should be. For instance, I can see the following two in Launchpad: https://translations.edge.launchpad.net/ubuntu/intrepid/+source/kdebase-workspace/+pots/desktop-kdebase-workspace https://translations.edge.launchpad.net/ubuntu/intrepid/+source/kdebase-runtime/+pots/desktop-kdebase-runtime They seem closely related, and related to desktop-kdebase one as well. They need more investigation to see what's the right thing here. I'll try to find someone who can tell us what's the issue here. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Duplicate document for Italian?
Hi Matthew, Milo, У суб, 11. 10 2008. у 14:45 +0100, Matthew East пише: On Sat, Oct 11, 2008 at 1:52 PM, Milo Casagrande [EMAIL PROTECTED] wrote: https://translations.launchpad.net/ubuntu/intrepid/+source/ubuntu-docs/+pots/about-ubuntu/it_IT/+translate The problem is that there's also this one: https://translations.launchpad.net/ubuntu/intrepid/+source/ubuntu-docs/+pots/about-ubuntu/it/+translate I think this is a Launchpad issue, someone has started a translation for it_IT... You should contact the Launchpad admins to remove localisation for it_IT on the basis that the it locale is the standard one. Not actually an issue in Launchpad. We generally hide such 'locales', but in certain cases, they are there and expected to be translated. Most prominent example is libgweather-locations which uses translations for setting a default location for gweather-applet (has stuff like es_MX, es_AR etc, even if only es is usually used for translations). There might be others. This is the reason why we need to allow such translations. The user probably hacked URL to get to the page and then added some translations, simply because he's not a member of the Ubuntu Italian translation group. If you want this removed, please file a ticket on answers.launchpad.net/rosetta so we don't forget about it. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: ubuntu-docs updates for translation into Intrepid
Hi Matthew, У сре, 01. 10 2008. у 12:57 +0100, Matthew East пише: I can't help as to when these templates will be available in Launchpad though. Based on what Ricardo said, it it doesn't seem like any templates have been processed by Launchpad since 4 August 2008. We've got a bunch of duplicate ubuntu-docs templates in the queue (all with differing paths). It's very likely that the paths under which Ubuntu packages provide POT files are different from what you use, so we have no idea which ones are the 'real' ones. For example, in our database we've got an add-applications.pot with a path of ubuntu/add-applications/po/add-applications.pot (or eg. server-guide prefixed with generic/ instead of ubuntu/) yet import queue[1] uses: add-applications/po/add-applications.pot So, my guess is that source package has been changed in this way (eg. assuming a split between kubuntu and ubuntu docs into separate source packages or something similar), but nobody has manually updated the paths. I've done that now for ubuntu-docs, but interestingly enough kubuntu-docs is even more confusing (we've got both templates prefixed with kubuntu/ and docs/ and without any prefixes, and when looking at both, it probably confused us about ubuntu-docs as well). I tried pinging you the other day on IRC, but then got busy with other stuff. Anyway, if there's anyone who can help us resolve the situation with *ubuntu-docs, I guess it's you, so feel free to get in touch and we'll look into solving everything live. Cheers, Danilo [1]https://translations.edge.launchpad.net/ubuntu/intrepid/+source/ubuntu-docs/+imports?field.filter_status=allfield.filter_extension=pot -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: ubuntu-docs updates for translation into Intrepid
Hi Matthew, У чет, 02. 10 2008. у 09:59 +0100, Matthew East пише: Hi Danilo, From Hardy to Intrepid the paths of the pot (and po) files have been changed as follows: ubuntu/add-applications/po/add-applications.pot add-applications/po/add-applications.pot (i.e. the preliminary ubuntu/ and generic/ prefixes have been removed). However, this is *not* a change done during the release cycle, the very first package uploaded to Intrepid had this change, so there is no reason that I can see for Launchpad to have been confused by it. Depends on how you assume the Launchpad is designed. We are not auto-approving sourcepackages with multiple templates in them, and especially not if they change paths. Basically, there are quite a few possible improvements, but when you see what we have seen (people uploading packages which use entirely different POT file names from one upload to the other), there is not much you can do in providing a generic solution unless you spend quite some time exploring it. From recent discussions with Ubuntu people, we are considering special casing Ubuntu packages, but that requires more work, and we've not yet scheduled it. Moreover, we are talking about 4 August 2008 - two months ago! There was some miscommunication between Ubuntu and Launchpad teams about sharing responsibilities for template approvals, and nothing ended up being looked at in the Ubuntu queue. We've tracked the problem down only recently (about a week or two ago), and have since worked hard to resolve all the remaining issues. Surely the solution is just to look at the most recent upload? The structure of kubuntu-docs (both in the bzr branch and the source package) looks to me to follow the docs/ prefix. But if there was confusion, it's the simplest thing in the world to ask for clarification when that arises. I agree, except that we were not even supposed to look at these things anymore (minus the miscommunication problem, so we ended up looking at it when we realised the sitatuion became critical). I wonder if there is any way that package uploaders or maintainers could be more involved in the pot template approval / review process? At the moment there seem to be serious communication issues... They indeed could. We are helping set up an Ubuntu Translations Coordinator team (at the moment led by Arne Goetje, but Canonical is hiring a dedicated person for the role, and we are hoping for community participation) which would get a lot of power in managing Ubuntu templates and translations in Launchpad. How the team organizes themselves from then on is up to the Ubuntu guys (i.e. including packagers and maintainers), and we'd work in implementing the policies that suit them best. That will also allow us to concentrate on actual Launchpad hacking, trying to spend more time on implementing features Ubuntu community needs than managing templates which can very well be done by somebody from the community who would not need to do so much investigation before they could set it up (i.e. a packager is bound to know quite a few details). I tried pinging you the other day on IRC, but then got busy with other stuff. Anyway, if there's anyone who can help us resolve the situation with *ubuntu-docs, I guess it's you, so feel free to get in touch and we'll look into solving everything live. I'm currently without internet at home, so can't access irc. But I check my email and mail to this list regularly. Ok, then email it will be for resolving this. I'll get on to fixing kubuntu-docs template paths as well. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: ubuntu-docs updates for translation into Intrepid
У чет, 02. 10 2008. у 14:17 +0100, Matthew East пише: This is a bit of a mess. I don't think the maintainers of kubuntu-docs have thought about this issue much. The current layout of the branch appears to use the latter: http://www.veza.co.uk/ask But the system used by ubuntu-docs and which is simpler, in my opinion, is the former one. Let's use the former one and I will fix the kubuntu-docs package when I get working internet. Ok, sure: I'll leave the paths as they are now (I've just changed 'kubuntu/' prefix to 'docs/'). Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: No KDE upstream translations imported to Rosetta?
Hi Erdal, Jannick, У уто, 23. 09 2008. у 17:49 +0200, Erdal Ronahi пише: On Sat, Sep 13, 2008 at 4:41 PM, Jannick Kuhr [EMAIL PROTECTED] wrote: I just noticed that we have now translation templates for Intrepid. So we have about one month for translations. But even worse is, that at least for KDE no translations have been imported. For german I know that KDE 4.1.1 is almost completly translated, but in Rosetta we just have 50% translated strings, probably the ones already existing in KDE3. There was no answer to this post from 10 days ago, bu I share the same concern. All the KDE translations for Kurdish are those which were already in Launchpad, nothing seems to have been imported from KDE 4 upstream. We are working on a solution. KDE has changed the layout of their translations, and our system wasn't ready for it. At the same time, we switched responsibilities around 4 months ago, and there was some misunderstanding there so nobody raised the issue with us. We are doing a manual approval right now, and that should be done by the week's end (i.e. everything should be both approved and imported). And also planning for catching this earlier in the future, and improving the system. Further official information on that later. Sorry for not keeping you in the loop. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: How to get a new language for Ubuntu
Hi Erdal, У уто, 16. 09 2008. у 13:03 +0200, Erdal Ronahi пише: Hi folks, I could nowhere find information about how to get a new language that is already in Launchpad into Ubuntu with language packs and all. Therefore I have filed a bug for language packs in Kurdish Sorani (ckb): https://bugs.launchpad.net/ubuntu/+bug/266975 Is this the right way to request it? Who can help? I remember hearing Martin Pitt that they can't add new packages to Ubuntu main after the initial release. Maybe that has changed since, but filing a bug should be a good way to get their attention. Though, you may want to contact Arne Goetje or Martin Pitt directly, just in case. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: BSD licence
Hi Luca, Yesterday at 12:05, luca innurindi wrote: I don't understand, but these strings came from upstream translations? If yes, the Ubuntu translators mustn't modify them without asking to the upstream translators. License changes will apply only to work contributed directly through Launchpad: upstream translations are not treated under the same rules. Our alternative solution would be not to show suggestions from other projects, but that would defeat the purpose of having a large, shared translations database. Also, I wonder how are BSD-licensed translations negatively affecting your upstream project? I think they negatively affect also the Ubuntu translations made in Launchpad, because who spends some time and energy for providing a quality translation if someone can later distribute this one in a closed way and under his own license? The BSD licence can encourage the behaviour of profiting from the others' work without costs. https://help.launchpad.net/Translations/LicensingFAQ#Does%20that%20mean%20my%20translations%20may%20be%20used%20in%20proprietary%20software? So, while we do understand there are some risks, we feel they are very low. And we are not alone in that, FSF feels the same way (judging by their actions): http://translationproject.org/html/whydisclaim.html As you can see there, many GPL projects which otherwise require strict copyright assignment in paper, require copyright _disclaimers_ when it comes to translations (disclaiming a copyright means that you are giving your work out into public domain; this is even worse than what BSD license does: BSD license allows you to still keep at least some rights, and in some countries, you can even revoke it if your moral rights have been violated). So I fear a lack of motivation for contributing to the Ubuntu translations if we use this license amd my big question is: What's the rationale for using this license? I ask because I haven't seen till now any discussion in this ml about this change. We've had a lot of discussion in the past (some on now extinct rosetta-users) list, and had more input from Launchpad Beta testers. I am sorry to hear that you'd lose the motivation to do any translations for Ubuntu, though. Rationale is provided on the license question page, and also in the FAQ: https://help.launchpad.net/Translations/LicensingFAQ#Why%20is%20this%20needed? (i.e. GNU applications, including those under GPL with strict copyright assignment in writing, use completely public domain translations) If they are under GPL, this isn't possible because the translation makes a derived work. Could you make some examples of this behaviour? Yes, look at the above mentioned TranslationProject page. FSF asks all translators to submit their translations into public domain. This is also mentioned in the FAQ: https://help.launchpad.net/Translations/LicensingFAQ#Why%20not%20public%20domain%20like%20the%20FSF%27s%20Translation%20Project? Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: BSD licence
Hi Caroline, Yesterday at 20:32, Caroline Ford wrote: I'm now worried that we (upstream) may have to remove the translations we synced from Rosetta. Aren't they currently under the license upstream chooses? In theory, yes. However, it was easy to re-use suggestions from other projects, so people _have_ reused suggestions with different licenses already. Basically, we can say that we put the responsibility on translators to know what they can relicense under project's license, and in most cases, they were not really allowed to (i.e. one can't relicense else's stuff). If you are interested in being totally legal, it's a choice between you accepting contributions under BSD license, or accepting contributions under a bunch of other free software licenses (i.e. GPL, LGPL, MPL,...) — because suggestions, which translators have probably made use of, came under that bunch of licenses. I feel the former option is both better and easier for you. Our alternative solution would be not to show suggestions from other projects, but that would defeat the purpose of having a large, shared translations database. Also, I wonder how are BSD-licensed translations negatively affecting your upstream project? (i.e. GNU applications, including those under GPL with strict copyright assignment in writing, use completely public domain translations) Cheers, Danilo -- 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
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 was committed together). As far as 'old style' diffs are
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
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 talking about relatively short
Re: [be] Compiz Translation
Hi Carlos, Alexander, Yesterday at 15:31, Carlos Perelló Marín wrote: Any removal we do right now is useless, because with next package upload, the problem will appear again. Can we not also put the po/be.po to 'Blocked' in the import queue? (of course, it would be easy to forget to unblock it) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Glade-3 in packs?
Hi Djihed, Yesterday at 15:05, Djihed Afifi wrote: I don't think your decision is sound though. So because it doesn't do what launchpad expects it to do, you just drop its translations from packages? It's not our decision: it's a technically hard problem. The only assumption we make is that packages will contain proper POT and PO files. If that doesn't happen, it's easier to fix it in a package, than to try to construct a reasonable POT from all the PO files (i.e. you may end up with too many messages for translation which are obsolete, thus making translators do unneeded work, you may have conflicting messages in different PO files, etc). We did discuss something like this: https://blueprints.launchpad.net/rosetta/+spec/autogenerate-missing-templates-in-packages Anyway, we have not yet dedicated to working on this, simply because of the above reasons. What happens to an ordinary person building the package from tarball sources, do they lose translations? No, but I probably miss your point. What they, however, do lose is the ability to get updates with future language pack updates (the plan for Gutsy is to issue them monthly). Ubuntu is so far the best distribution when it comes to propagating translator work to their users (imo, though there's a lot to improve still), and that's solely due to Launchpad/Ubuntu Not the right decision I believe. It's technically very hard to do anything else properly. At this time, I'm wondering how many other packages are dropping translations because of Launchpad. Not too many, we've had a few (I remember one other from the last 5-6 months) bug reports like this. Anyway, this is not because of Launchpad, this is because we're providing language packs for Ubuntu, and want to make sure that some data is at least correct. Launchpad itself works for much more than just intltool-enabled modules, so it can't regenerate POT files in the way damned-lies (on l10n.gnome.org) does. And, fwiw, this might as well be broken behaviour in upstream Glade3: i.e. standard intltool build rules always create a POT file and put it in a tarball. There's a lot of sense in that, and not least of them: how would you start translating a package if it comes with no POT? Anyway, a short-term solution is to fix the package. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Next steps improving Rosetta
Hi Timo, On Tuesday at 13:48, Timo Jyrinki wrote: Thanks for the feature that we can now finally fix the possible damages done in Rosetta by selecting the Packaged translation, and keep the improvements so that we can at least manually send them upstream. You are welcome: there are more improvements coming for Translations :) You may be surprised at how much our ideas match. And entire team is now in the sprint, and we are discussing further improvements, and when can we get to what. I hope all the best to those languages that took everyone willing to their teams and had more havoc than our language (Finnish). We had some damages, but nothing that we now cannot repair. And if some language team still hasn't established any clear requirements for the members, I recommend having such. QA is still too hard to do in Launchpad to accept any willing people to the translation teams. I'd hope to see the following improvements in Rosetta in the future: 1. mass revert, meaning an upload PO file option where one can select treat this as upstream and overwrite any Rosetta changes. I've currently clicked through eg. one package's 400 changed in Rosetta strings, in both gutsy and feisty, that were caused by an earlier manual upload of upstream translation that is now outdated but marked as having been done in Rosetta. mass revert would be very welcome if we had more packages like this Already planned, but as a manual step per PO file: https://blueprints.launchpad.net/rosetta/+spec/revert-translation-to-packaged 2. This one would be _really_ welcome: A new column, maybe optional, to the translations list called Changed in Rosetta, that has the number of changed strings in Rosetta per package. This would allow us to sort by the most changed packages and examine those in more detail, possibly reverting to upstream or taking the improvements to upstream. Discussed during the sprint: https://blueprints.launchpad.net/rosetta/+spec/translation-status-for-reviewer 3. Download option download only changed. This would allow for a neater way of having the improvements to be sent to upstream. Currently I've left the improvements I approve in Rosetta, and sent an URL to the changed strings in a package to the GNOME upstream language team leader, who is luckily in our translation team too and willing to copy-paste a few tens of strings from the web pages to the SVN translation files. Also discussed during the sprint: https://blueprints.launchpad.net/rosetta/+spec/export-changed-in-launchpad https://blueprints.launchpad.net/rosetta/+spec/export-new-translations https://blueprints.launchpad.net/rosetta/+spec/export-incremental-translation-tarball (the last one would include all the changed or new translations in LP compared to packaged; reasoning for having 3 at the moment is on the respective pages) Could you consider these in your future plans, if they're not there yet? In a short term, the 2nd improvement would be the most welcome, since it enables teams to check for possible bigger damages more easily. Of course, if big damages are found, 1st improvement could be very handy. Today is our last day of the 'sprint' (a get-together where we discuss our future plans, and make a concrete plan for the next 2-3 months). We'll consider your input when setting priorities for the blueprints, and set milestones for the future: https://launchpad.net/rosetta/+milestone/1.1.8 (late August) https://launchpad.net/rosetta/+milestone/1.1.9 (late September) Note that it commonly happens that some items move from one cycle to the next, since it's hard to predict design/programming/testing effort needed. So, the above links don't show exactly what will happen when, but should be a good approximation once we fill them up. Btw, I tried to use Firefox extension to automatically select Packaged form items on a page, but unfortunately the names of the items are IMO unidentifiable from others. If we don't come to implementing per-po file reversion in the short term, I'd suggest you make a blueprint describing what feature do you want or need (none of us is familiar with Firefox extension you might be using or trying to write). Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Gutsy translations now open!
Hi Matt, others, Thanks for voicing your concerns. Yesterday at 17:59, Matthew East wrote: On Tue, June 12, 2007 4:48 pm, Daniel Nylander wrote: This means: _Co-operate_ with your upstream GNOME translation team! That goes without saying. However, I had intended to raise a slightly more complex question - in order to know *how* to cooperate, we need to know what Launchpad's policy is in relation to upstream/Ubuntu translations in respect of this new early opening policy and how it works. Early opening has it's benefits: 1. Those translating using Launchpad exclusively have more time to translate 2. Ubuntu gets language packs right away These are big enough that I think it's worth announcing and caring about them. I know most of the people who voiced their opinions here are upstream translators as well, and they will also get a benefit: they'll be able to test upstream translations in Ubuntu, albeit only when upstreams release new packages. For example, GNOME 2.19.3 has been released about a week ago, and that included Metacity 2.19.13, which is already imported: http://ftp.gnome.org/pub/gnome/sources/metacity/2.19/ https://launchpad.net/ubuntu/gutsy/+source/metacity/ So, even if we were aware of the problems, and they do exist, the bottom line is that in practice, it's not that bad. And whatever is the problem, it has also existed before. Basically, most of the problem we have now is due to previous changes to upstream translations, and that will be solved with the ability to revert more easily in the 1.1.6 release of Launchpad, due at the end of June. And I understand it may seem like something not to brag yourself about going from bad to just so-so, but I still feel this is a major step forward for everyone: including upstream translations, who'll get more exposure in unstable Ubuntu releases. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Gutsy translations now open!
Hi Claude, Jannick, Yesterday at 17:36, Jannick Kuhr wrote: Am Dienstag, 12. Juni 2007 schrieb Claude Paroz: I don't know if this is really a good idea, as GNOME didn't even enter string freeze... Please, team leaders, warn your translators not to touche GNOME (and possibly KDE) strings, at least until GNOME 2.20 is out ! I have exactly the same doubts regarding this issue. Probably it would be the best to lock KDE and Gnome translations for the first months. There are teams doing translations directly in Launchpad, even for KDE and GNOME, and then submitting them upstream. It would be a very bad idea to actually push them away from Launchpad, at least from our POV. It is a VERY bad idea to import beta versions of programs to Rosetta. Please lock this apps until the upstream translation process is finished! Not really: this actually means that with enough discipline (i.e. not going around and randomly translating stuff in Ubuntu Gutsy po files), even upstream translators can benefit: latest translations from KDE/GNOME packages will get into Gutsy, and Gutsy language packs, which will now be available on a daily basis from official repositories. So, you could easily say goodbye to GARNOME, jhbuild for GNOME (there's probably something similar which builds KDE from SVN or tarballs), and just use Ubuntu Gutsy to test how your translations look. I am working for the german KDE translation team on the translation of KTorrent. Now I had to see that a beta version of this app has been imported to Rosetta with a lot of untranslated stings. This will result in a fork of the translation and lost efforts on both sides. It makes me a little bit sad to see that a reasonable cooperation and coordination between upstream and Ubuntu still does not exist. This is a different problem: we haven't encouraged enough cooperation between Ubuntu translation teams and upstream teams. Basically, this would be the same problem that happens in upstream teams: two people start translating a single PO file without letting each other know, so we end up with wasted work. Here it's only more pronounced because of the larger distance between the teams. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Translations in zope3
Hi Daniel, On Tuesday at 21:22, Daniel Nylander wrote: I'm a bit confused here. The source code for Zope 3.3.1 contains a lot of Swedish translations but none in Rosetta. Where can I find the strings listed in Rosetta in the source code? Do they actually get imported? They do not get imported automatically, at least not yet (that's a planned feature, though). I advise you contact Zope 3 developers directly and ask them to upload all the translated PO files as well. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Deadlines for ubuntu-docs translations
Hi Don, Matthew, On April 4th, Don Scorgie wrote: The XML file in question is /usr/share/yelp/toc.xml If you open it, you'll notice none of the front page stuff is translated, but everything else is (title elements). Dunno what needs doing, but it should be the same as any other (e.g.) .desktop file update. It's not the same for Ubuntu, since .desktop files are translated based on PO/MO files at run-time. Of course, this is just a partial solution to intltool language pack usage, and why I didn't accept Takao's patch to intltool to allow rebuilding just .desktop files: you've got to support everything else in the same manner (with everything else being .xml, .schemas, .server, and similar files; Ubuntu, I believe, already hacks in support for .server files as well). For those interested, see http://bugzilla.gnome.org/show_bug.cgi?id=309566 Until a distribution decides to use this, you'll have to recompile packages to include new translations in static files. Cheers, Danilo -- ubuntu-translators mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Kubuntu-docs and Ubuntu-docs edgy-to-feisty issue
Hi Mikel, On Sunday at 20:17, mikel paskual wrote: https://translations.launchpad.net/ubuntu/feisty/+source/kubuntu-docs/+pots/basic-concepts/eu/14/+translate https://translations.launchpad.net/ubuntu/edgy/+source/kubuntu-docs/+pots/desktopguide/eu/5/+translate They are not the same strings. One references eg. 'kubuntu.odt' and the old one 'cheeses.odt'. Launchpad is currently using only exact string matching, not similarity matching. Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Quick but important fixes
Today at 12:56, Jannick Kuhr wrote: Am Mittwoch, 24. Januar 2007 19:16 schrieb Krzysztof Lichota: Well, it would be nice to fix bug which spoils all KDE translations with plural forms leaving them untranslated or showing BROKEN TRANSLATION (for example on Adept updater icon, right in front of new users). It has not been fixed for 7 months now. https://bugs.launchpad.net/rosetta/+bug/46982 This would be so great :) And it requires more than a day's work, because it depends on some other work being done first. So, it's not doable on single Fix-It-Friday, but I'll be getting to it real soon. It's really high on my priority list :) Cheers, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Reverting translator-credits
Hi all, Because of repeated problems we had with messed-up upstream translator-credits (and translator_credits), we've reverted it to the upstream provided translations. The reasons are multiple, so let me highlight some of them: 1. Some Ubuntu translators have replaced the credits, which is actually wrong and not playing nice 2. We had numerous problems with translating it, since it's a single-line original English string, and is usually translated to multi-line string, which Rosetta sometimes caused problems for (sometimes even the reason behind 1.) 3. We have a plan to solve translator credits in a better way, and basically disable any translator-credits changes by hand. The plan includes allowing only adding-to translator-credits, and doing that automatically using any significant contributors through Rosetta (we keep information about all the past contributors as well, so as soon as we implement the proper solution, your credits will be back). I know this is going to cause problems for some of you, so we deeply apologize about it, but it's all part of actually creating a proper solution to the problem instead. Thanks, Danilo -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
