Kinyarwanda coordinator (unresponsive / unreachable)
Tried to reach Steve Murphy at the address listed, got a bounce (see below). http://l10n.gnome.org/teams/rw cjl volunteer Sugar Labs / OLPC / eToys Poolte admin -- Forwarded message -- From: Mail Delivery Subsystem Date: Mon, Apr 18, 2011 at 12:04 PM Subject: Delivery Status Notification (Failure) To: cjlhomeaddr...@gmail.com Delivery to the following recipient failed permanently: m...@e-tools.com Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 Sorry, no mailbox here by that name. (#5.1.1) (state 14). - Original message - MIME-Version: 1.0 Received: by 10.204.154.219 with SMTP id p27mr1452739bkw.110.1303142679164; Mon, 18 Apr 2011 09:04:39 -0700 (PDT) Received: by 10.204.102.139 with HTTP; Mon, 18 Apr 2011 09:04:39 -0700 (PDT) Date: Mon, 18 Apr 2011 12:04:39 -0400 Message-ID: Subject: Kinyarwanda L10n From: Chris Leonard To: m...@e-tools.com Content-Type: multipart/alternative; boundary=0015175cfa1e7bb70c04a1338c00 Dear Steve, Are you still active in Kinyarwanda localization? I ask because One Laptop per Child has an active effort ongoing to localize the Sugar user interface and OLPC builds are dual boot in Sugar and GNOME, so there are certain GNOME modules that it would be really nice to have localized. OLPC has a Learning Team based in Rwanda and I'm thinking I would like to get them engaged in the upstream so that the bits flow down to us (as downstream). http://translate.sugarlabs.org/rw/ Regards, cjl volunteer SUgar Labs / OLPC / eToys Pootle admin ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Glibc locale creation
On Fri, May 13, 2011 at 2:49 PM, Claude Paroz wrote: > Hi, > > For those interested in glibc locales, I recently created a small Django > application to help visualizing and editing those famous locale files. > > http://lh.2xlibre.net > > Talk to me if you have to work on a new locale to add. Well, I admit I > have still no expertise in LC_CTYPE or LC_COLLATE, so hopefully your > language script is not too different from an exiting one :-P > > I even blogged about it (people knowing me understand what exploit it > is :-) > http://www.2xlibre.net/blog/2011/05/13/glibc-locales-need-help/ > > Claude, Have you ever tried these tools for locale creation and testing? http://translate.sourceforge.net/wiki/guide/locales/glibc I was wondering how they compare to / complement yours. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Request for consideration - OLPC
Dear GNOME-i18n teams, When setting priorities for your team, please consider that the One Laptop per Child (OLPC) project needs the packages listed below. OLPC builds are now dual-boot in Sugar and GNOME user interfaces. Having these packages localized in the upstream is quite important to us and we are tracking their progress in order to encourage our localizers to contribute upstream. http://translate.sugarlabs.org/projects/upstream_l10n/ Please consider giving some attention to these packages in your language, these strings may be going out to some of the million-plus laptops in the hands of children around the world. http://olpcmap.net/ empathy eog evince file-roller gedit gimp gnome-desktop gnome-panel gnome-session gnome-terminal gnumeric libbonobo libbonoboui libgdata libgnome-keyring libgnome libgnomeui libgsf libwnck metacity nautilus NetworkManager-gnome notification-daemon PolicyKit-gnome totem-pl-parser totem xdg-user-dirs-gtk zenity Warmest Regards. cjl volunteer Sugar Labs / OLPC / eToys Pootle admin http://translate.sugarlabs.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for consideration - OLPC
On Fri, Jul 15, 2011 at 4:47 AM, Claude Paroz wrote: > If noone objects and if you give us the exact branches targeted by the > upcoming OLPC release, we could create an OLPC release set on > l10n.gnome.org. Dear Claude, I have forwarded your kind offer to the OLPC-devel list. I'm just a L10n coordinator and I think that the current release manager (Daniel Drake) would be in a better position to respond. 11.2.0 is going to be out in a few days, so your offer might not have an immediate impact (things being locked in at the moment with RC4 published already), but it can be anticipated that there may be fast-follow-on 11.2.1 release that might benefit (also allowing sufficient time for localizers to do their work). The branches used are generally 2.32 (or at least most current pre-3.0). Sugar Labs / OLPC are in the process of developing the roadmap forward to gtk3+ and PyGi and so at some point I imagine the 3.0 packages will also be needed, but that is "future-tense imperfect". A full list of packages for a very recent development build can be found at the link below (not all of them GNOME packages), but I'm not 100% sure if there have been any changes when 11.2.0 went into release candidate status. Hopefully the OLPC devels can shed more light on that. http://build.laptop.org/11.2.0/os23/xo-1/os23.packages.txt Warmest Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Request for consideration - OLPC
On Fri, Jul 15, 2011 at 11:53 AM, Chris Leonard wrote: > A full list of packages for a very recent development build can be > found at the link below (not all of them GNOME packages), but I'm not > 100% sure if there have been any changes when 11.2.0 went into release > candidate status. Hopefully the OLPC devels can shed more light on > that. > > http://build.laptop.org/11.2.0/os23/xo-1/os23.packages.txt > The latest package list for the current RC4 (build 873) is here: http://download.laptop.org/xo-1/os/candidate/873/os873.packages.txt I can try to parse out the non-GNOME packages (there are also Translate Project hosted packages in that list) if it would help. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME shell i18n
On Wed, Jul 27, 2011 at 4:28 AM, F Wolff wrote: > > Hi everybody > > GNOME 3.0 came and went, and i18n seemed to never be a goal of GNOME > 3.0. I'm hoping things can improve in future releases, so I'm trying to > follow up on some bugs that affect i18n that I have reported before > which haven't received attention yet. > > In which cases are we allowed to fix i18n issues or other errors in the > source text ourselves? Even in a case with a patch supplied in Bugzilla > I'm not necessarily getting a response. Of course everybody is busy, but > it seems that some i18n issues are simply ignored while other things are > getting attention, so I'm wondering to what extent we can still count on > good i18n being an important project goal and hold developers to it just > as we can for usability, security or other important issues. > > As a case in point, can people speaking other languages please comment > on this bug? > https://bugzilla.gnome.org/show_bug.cgi?id=644090 > Particularly the use/non-use of plurals is worrying to me, even though > it doesn't affect Afrikaans as badly as it affects other languages (as > far as I know). > > Keep well > Friedel Speaking on behalf of a dowstream currently working on about 130 languages and dialects and distributing a Sugar / GNOME dualboot to well over one million users around the world, but most especially to non-English speakers, I must speak in support of Friedel's concerns that i18n issues should be addressed as a high priority. I'm confident that all of you share the same sentiment to some degree. It is my experience that the i18n / L10n focused community members (like all of us on this list) need to speak up and make their voices and concerns heard by the developers, who are often deeply (and productively) focused on technical advancement. It is for the good of the overall project as proper i18n has the potential to vastly multiply the potential "customer base" of the software and is a key element in winning over new users in other languages. FOSS developer's are generally responsive to arguments that get their work in the hands of more people and it is sometimes just a matter of education and gentle poking to get these issues addressed. The task of doing that education and poking falls to the i18n team members. I see Friedel's posting in that light as a call to the i18n community for proactive engagement with the developers to make the needs of the language communities we represent by proxy heard and I am supportive. cjl volunteer Sugar Labs / OKLPC / eToys Pootle admin ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Reduced POT files
Claude, Can I get a pointer to the tricks used to produce "reduced" PO files for some packages? I'd like to help the Gnash guys do the same and would like to learn how it's done in Damned Lies. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Status of Dzongkha translations
On Sat, Sep 3, 2011 at 5:08 PM, Gil Forcada wrote: > El ds 03 de 09 de 2011 a les 22:33 +0200, en/na Andre Klapper va > escriure: >> Hi, >> >> Yesterday I tried to contact ~17 GNOME translation team leaders of teams >> that look like losing translation coverage[1]. >> >> (In general I think that the GNOME translation community should be more >> active in identifying potential problems and help with outreach to >> downstream translation teams[2][3][4]. >> I'm interested in thoughts of others on this.) > > I left Desktop Summit with this idea floating around, thanks for > bringing it up. > > Yes definitely is a must-do. LibreOffice, Firefox or Wikipedia have more > translation teams than GNOME, so... > - Which ones are we missing? > - How we can encourage them to start translating GNOME? > - How can make it easier for them to start with? > > And some more questions can arise, the second one (outreaching) is the > key, but how to tackle it? Just spamming them? :) Contacting with the > LibreOffice/Firefox/Wikipedia/whatever project l10n coordinators to ask > them about how to tackle their translation community? There's plenty of > debate around, anyone taking a lead? > > Cheers, > >> As a first result to mention here, I received a 550 delivery failure for >> the email address of the Dzongkha team[5] leader (CC'ed). >> >> How to proceed? Make it a "There is currently no established team for >> this language." on l10n.gnome.org for the time being? >> Contact downstream teams whether they somebody is interested in helping >> upstream? >> GNOME is certainly not alone to have difficulty maintaining language teams in certain languages. Upstream / downstream communication and collaboration on L10n is an important community development activity. In the case of the Sugar Labs / OLPC Pootle instance, I've created a set of dummy PO files that are intended to serve as upstream tracking tickets [1] that also leave a "trail of breadcrumbs" to the upstream projects we pull into the GNOME boot side of OLPC's dual-boot builds. The idea is to make clear to our L10n community how much we are dependent on the upstream for L10n bits and to encourage upstream (and downstream) migration of L10n skills. Claude Paroz was kind enough to create an OLPC release set that I can manage to make this easier to track within GNOME infrastructure. [2] We have also performed outreach to upstream projects that were using "send-PO-to-the-mailing-list" L10n workflows without a central database (e.g. AbiWord and Gnash) in the form of offering them hosting on our Pootle instance. [3] I believe there are a certain common patterns that can explain a decline from a high level of coverage over time. 1) A team forms galvanized by some one-time event, e.g .a conference, hackfest, grant funding, etc.) and achieves good coverage at a given point in time, but there is failure to maintain momentum and keep up with growing string sets. 2) Loss of activity by an individual "supersatar" localizer. For example (I ask only partly in jest), is there any FOSS project that wasn't mostly completed in Vietnamese by the inimitable Clytie Siddall? I believe that part of the answer is to actively encourage mobility within FOSS L10n communities, but to some extent that is a zero-sum game. Someone working on my strings is not working on yours and we must be careful to not appear to be trying to "poach" localizers from each other, which is mostly impossible anyway because localizers will work where they choose. Gnome localizers are always welcome to reach out to the Sugar Labs / OLPC / eToys L10n community via our list [4] and they are particularly welcome to prioritize their Gnome contributions to those packages we pull for our builds :-) I believe the more important approach is to increase the total number of people involved in L10n work, particularly in the non-European languages that generally have smaller L10n communities. The venues that seem worth reaching out to include: 1) Local Linux user groups. However, it must be understood that in certain cultures and countries an individual with the talents we are seeking will understandably be employing them fully to advance their family's economic circumstances. 2) Academia, particularly computer sciences and languages departments. 3) NGO's with large local footprints (particularly those engaged in ICT4D). 4) Ex-patriate communities looking to maintain a connection to their mother tongue and culture. 5 ) Multilingual FOSS developers. Surprisingly, they give freely of their own time to code, but are sometimes less inclined to spend time localizing another developer's strings or even their own code into their native language. There seems to be a belief that their time is best spent on developing new code, perhaps understandably, but I think emphasizing the amplifying effect of L10n on the potential audience for the whole FOSS ecosystem might convince some to take a break from coding during string freezes
Re: Russian in traditional orthography support
On Wed, Sep 14, 2011 at 3:25 AM, Ihar Hrachyshka wrote: > On 09/13/2011 09:58 PM, -скрыто- Алекса wrote: >> >> (In continuation of discussion from 2011-04-01) >> >> So what's about my team registration request? Since Gnome also provide GTK >> toolkit, it is important to have the support and standardized locale name >> there. >> >> ___ >> gnome-i18n mailing list >> gnome-i18n@gnome.org >> http://mail.gnome.org/mailman/listinfo/gnome-i18n > > Do you have libc locale assigned for this orthography? > /Ihar Wouldn't this be ru_RU ? cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New team for English Pig Latin epl
On Thu, Oct 13, 2011 at 2:15 AM, Andre Klapper wrote: > Hi, > > On Wed, 2011-10-12 at 19:51 +0200, Alexander Jansen wrote: > > English Pig Latin Hngliseus Gipus Natilus epl > > Is there a glibc locale for this, or have you applied for one in > http://sources.redhat.com/bugzilla ? > Probably needs to get it accepted as an ISO-639 code first, http://www.loc.gov/standards/iso639-2/php/iso639-2form.php let me know how that goes. . . > > For those that had no idea either: > https://secure.wikimedia.org/wikipedia/en/wiki/Pig_Latin > > As a native speaker, I think the request must for some variant like epl_NO because in epl_US, the language name would be "ig-Pay atin-Lay" and not "Gipus Natilus". cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New team for English Pig Latin epl
On Thu, Oct 13, 2011 at 3:02 AM, Claude Paroz wrote: > Le jeudi 13 octobre 2011 à 02:44 -0400, Chris Leonard a écrit : > > On Thu, Oct 13, 2011 at 2:15 AM, Andre Klapper wrote: > > Hi, > > > > On Wed, 2011-10-12 at 19:51 +0200, Alexander Jansen wrote: > > > English Pig Latin Hngliseus Gipus Natilus epl > > > > > > Is there a glibc locale for this, or have you applied for one > > in > > http://sources.redhat.com/bugzilla ? > > > > Probably needs to get it accepted as an ISO-639 code first, > > > > http://www.loc.gov/standards/iso639-2/php/iso639-2form.php > > > > let me know how that goes. . . > > Being a "language game", I somehow doubt that it will be accepted by > glibc or iso. > > > > > For those that had no idea either: > > https://secure.wikimedia.org/wikipedia/en/wiki/Pig_Latin > > > > > > As a native speaker, I think the request must for some variant like > > epl_NO because in epl_US, the language name would be "ig-Pay atin-Lay" > > and not "Gipus Natilus". > > I must admit I'm a bit hesitant about giving resources to those sort of > languages. Of course, nothing prevent anyone from creating the necessary > files for such languages, and then package them for extra installations > on any distro. > But we have to keep in mind that any new language do add costs globally: > setup time on infrastructure level, bandwith time for everyone who > checkout sources, storage cost, more longer language dropdowns, etc. > etc. For any real language, I'm convinced it's always worth the cost, > but not so for languages that have no real native speakers. > Don't we have enough languages on earth to have to add more? > > Sorry if I offended anyone. I'm always open to any counter-arguments :-) > > Claude > > I do apologize for not using tags in my message. I completely agree that "epl" would be a waste of resources and I also aplogize for wasting precious attention on a poor attempt at humor. On a more serious note, I am engaged in several projects to localize the Sugar UI for the OLPC XO laptop into indigenous languages of South and Central America (in particular in Mexicao and Peru). hus - Huastec (Téenek) has made excellent progress and the OLPC Mexico team may soon be tackling nah - Nahuatl A group in Peru is planning a translation marathon in Lima for Quechua [most likely the quz - Quechua (Cusco-Collao) variant] as well as aym - Aymara (Aru). glibc locales are in development and will be upstreamed when ready. There are certain advantages to working on Sugar L10n, as a graphic-heavy interface, we can provide a fairly fully localized interface on a small string budget (about 10K words covers Sugar and many educational "actviities". It may be some time before the teams are ready to take on a full Gnome L10n effort, but I will be encouraging them to consider the OLPC "release set" of Gnome packages in order to provide L10n in the Gnome dual-boot on OLPC builds, but we are starting with Sugar first for what I hope are obvious reasons. One can anticipate that raising kids to expect a native language computing experience will help drive more upstream L10n in future. If anyone has contacts interested in these indigenous languages or any number of other less-common languages from the less-developed regions that the OLPC effort is targeting, please feel free to join the effort on our Poolte server. http://translate.sugarlabs.org/ Warmest Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Google Code-in
On Fri, Oct 21, 2011 at 10:28 AM, Gil Forcada wrote: > El dv 21 de 10 de 2011 a les 11:36 +0200, en/na Kenneth Nielsen va > escriure: > > > > > If Gnome decides to participate I would also like to add a few > > localisation tasks. However, I am not sure if Gnome participation is > > planned this time around. I think previously some of the Gnome > > developers have offerede this oppotunity up, but there has not been much > > interest in it, so I am not sure if it will be offerede again. > > Hi, > > No matter if GNOME participates or not. We should collect some small > task ideas related to i18n/l10n. > > Who starts a live.gnome.org page with his/her own ideas? :) > > A collection site for small to mid-size projects you can point people to is always a good idea. As an alternative to a wiki, some folks (like Sugar Labs) have a component in the bug tracker called "sugar-love" wher etickets may be accumulated. Not sure if Gnome would welcome the tracker being used that way, but it is another option and doesn't require wiki privs. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Google Code-In 2011: Tasks wanted!
On Wed, Oct 26, 2011 at 6:18 PM, Andre Klapper wrote: > [Please edit the recipients list if your answer is specific to your > mailing list to avoid unneeded cross-posting.] > > Google Code-In starts again. > GNOME took part in it last year already. > > > === What is Google Code-in (GCI)? === > > You might call it the "small sister" of Google Summer of Code. > It is a contest for 13-17 year old highschool students. > Tasks take 3-5 days and have a mentor assigned. > > Tasks can be in several categories: > * Code: Tasks related to writing or refactoring code > * Documentation: Tasks related to creating/editing documents > * Outreach: Tasks related to community management and outreach/marketing > * Quality Assurance: Tasks related to testing and ensuring code is of high > quality > * Research: Tasks related to studying a problem and recommending solutions > * Training: Tasks related to helping others learn more > * Translation: Tasks related to localization > * User Interface: Tasks related to user experience research or user > interface design and interaction > > For more info check out > > http://www.google-melange.com/gci/document/show/gci_program/google/gci2011/about > > > === How to participate === > > GNOME needs 5 tasks in each of the 8 categories (=40 tasks in total) > until October 31st in order to participate in GCI. > That's in a few days already, so hurry up if you have an idea! > That would be the first batch of tasks. > A second batch would be published on December 16th. > > Tasks need a clear description, one or more defined mentors, an expected > timeframe to solve them, and difficulty (easy, medium, hard). > > More info for mentors is available here: > http://code.google.com/p/google-code-in/wiki/GCIAdminMentorInformation > > No ideas? Check out for example KDE's list: > http://community.kde.org/GoogleCodeIn/2011/Ideas > > You could even add generic tasks: Add three GCI tasks "Fix a bug of your > choice for the product $foo in GNOME Bugzilla" (one easy, one medium and > one hard), let the student pick a bug, and then tell her/him whether to > claim the easy, medium or hard task for it. > > > === Criticism from last year === > > ...as it helps to avoid wrong expectations: > GCI is not GSoC. There is not enough time to create an "emotional > binding" to the project that the student works on. > I'd rather call it "drive-by contributions". > > Patches might need several iterations and you will need to be both > patient and reactive (as students cannot claim a new task until their > patch has been reviewed and marked as completed by mentors). > It might be helpful to mention in task descriptions your availability, > e.g. that you also have free weekends or don't plan to review > submissions on christmas holidays. > > > But all in all it is a good way to help young people to get a first idea > of FOSS and contributing to it, and to create some future contributors. > > Are you in? > > If so, go to https://live.gnome.org/GoogleCodeIn and add some ideas to > https://live.gnome.org/GoogleCodeIn/Tasks ! > > Unless you just list a lot of individual languages and files like the KDE folks, it acn be challenging t o come up with five i18n / L10n tasks. However, I took a shot at some ideas I had floating around in my head and I'm providing drafts for 2 here for comment / improvement. The first would be enhancing the utility of open-tran.eu and the second is just a more traditional QC checking step that (IMHO) should be done more than it currently is. cjl + Task Description: Develop web-page for semi-automated checking of PO files for matches to open-tran.eu strings. Expected results: The Open-Tran database pulls localization from large upstream projects: http://open-tran.eu/projects.html and provides a search capability on a phrase-by-phrase basis. It would be desirable to be able to upload a PO file and walk through it string-by-string making manual judgement calls about quality of the match to get a rapid start on a L10n effort. This is useful for (A) identification for harmonization of English strings between FOSS projects (i18n improvement) when performed English > English and (B) also for the transfer of translated strings between projects (with native speaker human judgement in the loop). Requirements: Web-coding skills DIfficuly: Estimated Time: Mentor: + Task Description: Run poconflict and inverted poconflict analysis of individual languages PO files from Damned Lies server. Expected results: Identified instances where the same English phrase is translated in different ways with poconflicts. Identify instances where the same foreign language string is used for two different English phrases with inverted poconflicts analysis. These should be investigated by a native speaker and possibly filed as L10n bugs. Not every conflict identified is necessarily an error, but they are often worth inve
Re: Burmese Translations Commit Request
On Mon, Nov 14, 2011 at 4:02 PM, Gil Forcada wrote: > El dl 14 de 11 de 2011 a les 22:34 +0700, en/na Theppitak > Karoonboonyanan va escriure: >> On Mon, Nov 14, 2011 at 3:23 PM, Theppitak Karoonboonyanan >> wrote: >> > On Mon, Nov 14, 2011 at 9:58 AM, Thura Hlaing wrote: >> >> Hello guys, I have already uploaded Burmese translations of several gnome >> >> 2.32 modules in gnome l10n site. >> >> Could someone commit those translations? Thanks in advance ... >> > >> > AFAIK, GNOME 2.x is no longer maintained nor released. Are you sure >> > you want to commit to the dead branch? Please consider working on 3.2 >> > as well, anyway. >> >> I've committed your translation to gnome-2-32, gnome-3-2 and master >> branches for eog [1]. If it's OK, I'll continue doing for the rest. >> >> [1] http://l10n.gnome.org/vertimus/eog/gnome-2-32/po/my >> >> Regards, > > It is also used on OLPC (or at least is on that release set > evince-2-32). > > I pushed evince and I'm going to continue pushing them if no one beats > me before :) > > Cheers, > > -- > Gil Forcada > Thank you. I can confirm that eog 2.32 (and evince 2,32) are still in use in the latest OLPC builds for the XO-1. eog-2.32.0-3.fc14.i686 evince-2.32.0-4.fc14.i686 evince-djvu-2.32.0-4.fc14.i686 evince-libs-2.32.0-4.fc14.i686 http://download.laptop.org/xo-1/os/official/latest/os883.packages.txt Progress is being made in moving forward to re-basing on newer Fedora versions, but we've got a substantial installed base (about 1 million laptops) that are still based of f14 and earlier). As build baselines change, I will maintain the OLPC release set accordingly. cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: translation project for local university
On Tue, Dec 6, 2011 at 11:01 PM, Umarzuki Mochlis wrote: > Hi everyone, > > I was contacted by a lecturer in a local university that he had approached > the dean at his university to have a project where students will volunteer > to the gnome translation in Malay and the university will get some sort of a > recognition for this effort. > > How this could be done. Any legalities involved? > > This could be a good start for a Gnome community in Malaysia. > > -- > Regards, > > Umarzuki Mochlis > http://debmal.my > Exactly what form of recognition would be needed? A blog post recognizing the contributions of the university students effort? A certificate suitable for framing? I am sincerely curious because reaching out to academic groups is one of the approaches I am considering for the SugarLabs / OLPC translation effort (downstream of Gnome). We often work on languages that are not very well represented in the usual on-line communities. This can make it challenging to find volunteer localizers for some of our languages and academia is an attractive recruiting ground. cjl Sugar Labs Translation Team Coordinator http://translate.sugarlabs.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New team for mexican spanish (es_MX)
2011/12/7 Jorge González : > Dear Israel, > > Have you noticed that there is a team for Neutral Spanish (es) and > that in case you really wanted to start a new team, instead of > collaborate with the current one, where people from all Spanish > speaking countries collaborate, you don't have to start from the > beginning? It would be much easier for you to take the Neutral Spanish > base, and work with it modifying whatever you need to transform it > into Spanish from Mexico. > > My 2 cents. At Sugar Labs / OLPC we have a large Spanish language user base across a number of countries and the consensus choice among our customers has been to *not* split into country-specific variants of Spanish. I am curious what words you have identified that you would translate differently? Computer software UI strings are not generally that rich in the sorts of cultural and cuisine terms that are a frequent source of regional variation in many languages (including Spanish). I firmly believe in linguistic self-determination, but I am not sure how different the translations of computer terms would be between es and es-MX, although I would be very interested in learning more. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: PO files headers and DL
2011/12/10 Daniel Mustieles García : > Hi all, > > I've been developing a small bash script to help me with some git tasks, > such as updating all my downloaded git clones, deleting all branches and, > the most important, commiting automatically PO files from the GUI (not > documentation). > > Well, at this momment, I'm working with the PO filenames to know where I > have to copy the PO file (i.e., anjuta.master.es.po must be copied in > anjuta/po/es.po). This is relatively easy, since GUI files are always > (unless a ver few exceptions) in the module/po folder, but this rule can't > be applied with documentation PO files (in the case of Anjuta, PO file is > located in anjuta/manuals/anjuta-manual). > > I've been talking with with Claude about the possibility to add a header > (maybe «X-Location»?) to PO files (both GUI and doc ones) containing the > folder in which the PO file is located, so I can easily parse it with my > script, simplifying it and ensuring I'm copying the PO file in the properly > location. This header could be added automatically by DL to PO files, and as > a PO file header, should not affect translations nor translators. > > We wolud like to ask teams coordinators If you agree adding this header to > PO files. Note that this header can be used out of the script, for example, > if you don't remember where libgda or anjuta's documentations are located. > > Of course, If anybody wants to take a look into (or use) the script, just > tell me and I'll send you a copy of it. I'm using it and works properly (I > still have not broken git with it ;-) ) > > Many thanks to all I am sympathetic to the sentiments expressed by Matej Urban in his restrained "rant" that the real answer is to ask developers to work towards uniformity wherever it is possible. At Sugar Labs, we face similar challenges when generating language packs that are self-installing scripts that contain the latest MO files (updated and overwritten nightly), so the notion of imposing the burden on the developer to explicitly specify within the PO file any necessary information about non-standard locations (either in the repo for PO files in your example or on the local filesystem for MO files in my language pack example) is interesting. I guess my obvious concern is what makes you think that these developers would be any better about documenting their non-standard practices than they are about following generally accepted practices about how to structure their repos? cjl Sugar Labs Translation Team Coordinator http://translate.sugarlabs.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations commit request
My Dear Gnomes, Sorry for the misdirected traffic. I had pinged Baurzhan about finishing off 2 dozen words on the Kahzakh AbiWord PO (which Sugar Labs hosts on our Pootle instance for collaborative purposes as we also do for Gnash PO files.) Baurzhan, I will upload your file to Pootle and one of the AbiWord devs will commit to their repo. Wishing all a festive winter solstice and whatever holiday might correspond with it in your culture. cjl Sugar Labs Translation Team Coordinator http://translate.sugarlabs.org/ On Mon, Dec 19, 2011 at 6:52 AM, Baurzhan Muftakhidinov wrote: > Hi, Chris > I've updated the translation and sent it to the Abiword-dev mailing list > > Cheers, > > On Sun, Dec 18, 2011 at 10:28 AM, Chris Leonard > wrote: >> On Sat, Dec 17, 2011 at 1:51 PM, Baurzhan Muftakhidinov >> wrote: >>> Hello! >>> >>> Could someone please commit the updated translations for Kazakh language >> >> Dear Baurzhan, >> >> It would be wonderful of you could finish off the lang-kk AbiWord PO >> files that you've worked on. >> >> http://translate.sugarlabs.org/kk/upstream_POT/ >> >> cjl >> Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Gnash release planned - urgent need for L10n help
Dear Gnome localizers. Rob Savoye is planning a new release of Gnash in mid-January. Gnash is the GNU SWF movie player, which can be run standalone on the desktop or an embedded device, as well as as a plugin for several browsers. http://www.gnu.org/software/gnash/ http://www.gnashdev.org/ Many strings have recently been added to the Gnash project and so I am making an urgent request for assistance to the Gnome localizers for help with this important sister GNU project effort. The goal is to achieve a reasonable level of L10n coverage, both in number of languages and in the percent completion of each language. Gnash has historically used a "download the POT, complete it and post it to the mailing list" L10n workflow. As you might expect, this results in relatively poor L10n coverage. At present, the Gnash repository /po directory has the following submissions (only 9 languages, none of them complete). http://git.savannah.gnu.org/cgit/gnash.git/tree/po Czech 79% Danish 83% English (UK)83% Finnish 7% French 17% German 7% Italian 3% Japanese 3% Spanish 83% This is a sad state of affairs for an important free software project used around the world. The Sugar Labs / OLPC / eToys localization community has been collaborating with the Gnash community by offering hosting for the Gnash PO files on our Pootle server and contributing to Gnash localization in appreciation of their work to provide a free / libre alternative to proprietary SWF / Flash players. gnash.po files hosted here: http://translate.sugarlabs.org/projects/upstream_POT/ The Gnash PO file is currently available for translation into these 90 languages. The Gnash PO file can be made available on Pootle in other languages upon request. Acholi, Afrikaans, Akan (Twi:Asante), Albanian, Amharic, Arabic, Armenian, Asturian, Aymara (Aru), Bamanankan, Basque, Belarusian, Belarusian-latin, Bengali, Breton, Bulgarian, Catalan, Chiga, Chinese (China), Chinese (Hong Kong), Chinese (Taiwan), Croatian, Czech, Danish, Dutch, English (United Kingdom), Esperanto, Estonian, Finnish, French, Fulah, Galician, Ganda, German, Greek, Hebrew, Hindi, Hungarian, Indonesian, Irish, Italian, Japanese, Kazakh, Khmer, Korean, Kurdish, Latvian, Lithuanian, Lojban, Macedonian, Malagasy, Malay, Mandinka, Marathi, Nahuatl languages, Nepali, Northern Sotho, Norwegian Bokmal, Norwegian Nynorsk, Pashto, Polish, Portuguese, Portuguese (Brazil), Quechua (Ayacucho-Chanka), Quechua (Cusco-Collao), Romanian, Russian, Sardinian, Serbian, Serbian-latin, Sinhala, Slovak, Slovenian, Songhai languages, Spanish, Swahili, Swedish, Swiss German, Tamil, Thai, Turkish, Tzotzil, Ukrainian, Urdu, Vietnamese, Welsh, Wolof, Yiddish, Zulu If you truly care about making free / libre software available in your native language, please consider contributing some time and effort to working on the Gnash L10n over the next few weeks. You have an opportunity to have a huge impact on the user experience of free software users and creating a viable alternative to using a proprietary SWF player. You should be able to download the gnash.po file for your language and work with it off-line in your favorite PO editor or you can register on our Pootle server and localize it on-line. If you choose to work off-line, please send your PO files to me and I will make sure that they get uploaded to our Pootle server. I will work with Rob Savoye (Gnash developer and release manager) to make sure that your contributions are included in the upcoming release. As the PO file for Gnash is quite large, off-line work may be fastest. I will try to see if it is possible to create something like a "reduced PO" file for Gnash that focuses on the most prominent UI strings, but in the meantime, there are many strings that need to be localized and this is a wonderful chance to make a big difference with your localization skills to start off the New Year (Gregorian). Please spread this message to any distro L10n communities that package Gnash. It would be awesome if we could turn the first few weeks of this New Year into a globally distributed translation marathon on behalf of Gnash. Thank you for your attention to this request. Time is of the essence to meet the new release date goal. Warmest Regards and a Happy and Healthy New Year to All. cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Gnash release planned - urgent need for L10n help
On Sat, Dec 31, 2011 at 8:44 AM, Mișu Moldovan wrote: > On Sat, Dec 31, 2011 at 08:50, Chris Leonard wrote: > [snip] >> As the PO file for Gnash is quite large, off-line work may be fastest. >> I will try to see if it is possible to create something like a >> "reduced PO" file for Gnash that focuses on the most prominent UI >> strings, but in the meantime, there are many strings that need to be >> localized and this is a wonderful chance to make a big difference with >> your localization skills to start off the New Year (Gregorian). > > I'm interested in a PO with the most important strings. I took a quick > look at the PO and besides being huge, it seems to largely consist of > very technical messages that make no sense to a regular user. > > Thanks, > > -- > mișu Thank you all for your replies. I am working on the "reduced PO" today and hope to have something more reasonable available very shortly. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Gnash release planned - urgent need for L10n help
On Sat, Dec 31, 2011 at 9:20 AM, Chris Leonard wrote: >> I'm interested in a PO with the most important strings. I took a quick >> look at the PO and besides being huge, it seems to largely consist of >> very technical messages that make no sense to a regular user. >> >> Thanks, >> >> -- >> mișu > > Thank you all for your replies. I am working on the "reduced PO" > today and hope to have something more reasonable available very > shortly. > > cjl A much more reasonable reduced-gnash.po file has been made available. 1542 words in 321 strings. After consulting with the Gnash-devs, I have included all UI strings derived from the code in the conveniently named GUI directory in the Gnash source repository. There may be some refinements to the reduced-gnash.po creation method, but for now, this is an excellent starting point. All strings submitted will be migrated into any new variation of the reduced-gnash.po and gnash.po files, so no localizer effort will be lost. I will be handling merging of the reduced PO into the complete template for the Gnash release in collaboration with Rob Savoye. Warmest Regards. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Tools to help with mnemonic l10n?
On Wed, Jan 11, 2012 at 5:00 AM, Byrial Jensen wrote: > Hi, > > When I translate button labels and menu texts etc., it may be difficult to > select good (that is unique) key mnemonics (the letters with a prepended > underscore) as I often do not know which options will be grouped together in > the same menu or window. > > I wonder if there is any tools to help with that. > > When the UI is made with glade, maybe the program which extracts the > translatable strings from the glade XML file could analyze the file enough > to insert comments into the pot file about which strings with mnemonics are > in the same group. This could help the translator, and it would be possible > for other tools such as for instance pofilter to check for possible mnemonic > conflicts in the translated po files. Do anything like this exist, or has > anyone plans to do like this? > > Best begards > - Byrial I don't know of any such tool, but I like your idea. I particulalry like the notion of a pofilter check, but on what basis will the algorithm know that the entries are in a common pulldown? One intermediate step would be improved translator comments in the PO file. This is still imperfect as depending on the sorting of the PO file as presented (some people go for alphabetical instead of appearance in code) , even the best manual annotation is not going to group the menu items as needed. Having reviewed many PO files with accelerators in many languages, I can tell you that localizer understanding of and implementation of accelerators is very uneven. Romance languages are generallty better (probably due to common root word origin) whereas languages in non-latin scripts tend to either skip the accelerator or simply leave it in place at the beginning. Don't forget the use of ampersand & as an accelerator in addition to underscore in various settings. http://translate.sourceforge.net/wiki/guide/translation/accelerators cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Gnash release planned - urgent need for L10n help
Thank you to everyone that has contributed Gnash strings for the latest release. There remains plenty of L10n work to be done, but isn't that always the case :-) cjl Sugar labs Tranaslstion team Corrdinator http://translate.sugarlabs.org/ On Sat, Dec 31, 2011 at 1:50 AM, Chris Leonard wrote: > Dear Gnome localizers. > > Rob Savoye is planning a new release of Gnash in mid-January. > > Gnash is the GNU SWF movie player, which can be run standalone on the > desktop or an embedded device, as well as as a plugin for several > browsers. > > http://www.gnu.org/software/gnash/ > http://www.gnashdev.org/ > > Many strings have recently been added to the Gnash project and so I am > making an urgent request for assistance to the Gnome localizers for > help with this important sister GNU project effort. The goal is to > achieve a reasonable level of L10n coverage, both in number of > languages and in the percent completion of each language. > > Gnash has historically used a "download the POT, complete it and post > it to the mailing list" L10n workflow. As you might expect, this > results in relatively poor L10n coverage. At present, the Gnash > repository /po directory has the following submissions (only 9 > languages, none of them complete). > > http://git.savannah.gnu.org/cgit/gnash.git/tree/po > > Czech 79% > Danish 83% > English (UK) 83% > Finnish 7% > French 17% > German 7% > Italian 3% > Japanese 3% > Spanish 83% > > > This is a sad state of affairs for an important free software project > used around the world. The Sugar Labs / OLPC / eToys localization > community has been collaborating with the Gnash community by offering > hosting for the Gnash PO files on our Pootle server and contributing > to Gnash localization in appreciation of their work to provide a free > / libre alternative to proprietary SWF / Flash players. > > gnash.po files hosted here: > http://translate.sugarlabs.org/projects/upstream_POT/ > > The Gnash PO file is currently available for translation into these 90 > languages. The Gnash PO file can be made available on Pootle in other > languages upon request. > > Acholi, Afrikaans, Akan (Twi:Asante), Albanian, Amharic, Arabic, > Armenian, Asturian, Aymara (Aru), Bamanankan, Basque, Belarusian, > Belarusian-latin, Bengali, Breton, Bulgarian, Catalan, Chiga, Chinese > (China), Chinese (Hong Kong), Chinese (Taiwan), Croatian, Czech, > Danish, Dutch, English (United Kingdom), Esperanto, Estonian, Finnish, > French, Fulah, Galician, Ganda, German, Greek, Hebrew, Hindi, > Hungarian, Indonesian, Irish, Italian, Japanese, Kazakh, Khmer, > Korean, Kurdish, Latvian, Lithuanian, Lojban, Macedonian, Malagasy, > Malay, Mandinka, Marathi, Nahuatl languages, Nepali, Northern Sotho, > Norwegian Bokmal, Norwegian Nynorsk, Pashto, Polish, Portuguese, > Portuguese (Brazil), Quechua (Ayacucho-Chanka), Quechua > (Cusco-Collao), Romanian, Russian, Sardinian, Serbian, Serbian-latin, > Sinhala, Slovak, Slovenian, Songhai languages, Spanish, Swahili, > Swedish, Swiss German, Tamil, Thai, Turkish, Tzotzil, Ukrainian, Urdu, > Vietnamese, Welsh, Wolof, Yiddish, Zulu > > If you truly care about making free / libre software available in > your native language, please consider contributing some time and > effort to working on the Gnash L10n over the next few weeks. You have > an opportunity to have a huge impact on the user experience of free > software users and creating a viable alternative to using a > proprietary SWF player. > > You should be able to download the gnash.po file for your language and > work with it off-line in your favorite PO editor or you can register > on our Pootle server and localize it on-line. If you choose to work > off-line, please send your PO files to me and I will make sure that > they get uploaded to our Pootle server. I will work with Rob Savoye > (Gnash developer and release manager) to make sure that your > contributions are included in the upcoming release. > > As the PO file for Gnash is quite large, off-line work may be fastest. > I will try to see if it is possible to create something like a > "reduced PO" file for Gnash that focuses on the most prominent UI > strings, but in the meantime, there are many strings that need to be > localized and this is a wonderful chance to make a big difference with > your localization skills to start off the New Year (Gregorian). > > Please spread this message to any distro L10n communities that package > Gnash. It would be awesome if we could turn the first few weeks of > this New Year into a globally distributed translation marathon on > behalf of Gnash. >
Re: Cleaning up https://live.gnome.org/TranslationProject
On Sat, Jan 14, 2012 at 3:47 PM, Andre Klapper wrote: > I'd like to clean up the frontpage of the wiki at > https://live.gnome.org/TranslationProject , as I like > https://live.gnome.org/DocumentationProject . +1 cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Gnome 3.2-te has reached 100%
On Fri, Mar 2, 2012 at 10:44 PM, Sasi Bhushan wrote: > Dear all, > Now Gnome 3.2 has reached 100% . Congratulations to the team of swecha and > all individuals who have worked for it. A herculean task! Telugu is the only > indian language which is 100%. > Congratulations, If you are looking for your next Gnome targets, there a e some Gnome hosted modules that would be useful to Sugar / OLPC in Telugu http://l10n.gnome.org/languages/te/olpc/ui/ GCompris is very popular with kids and WebKitGTK+ is increasingly important these days. Regards, cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Survey on bug tracking of software translations.
On Wed, Mar 14, 2012 at 4:55 AM, Kenneth Nielsen wrote: > Den 13-03-2012 23:59, Rūdolfs Mazurs skrev: >> >> Hello fellow translators! >> >> >> I have noticed that advanced translation bug tracking is too difficult >> to bother with in day to day use (at least for me) and I intend to >> simplify this process by making simplified and specialized bug tracker >> for translators. I was wondering, if other translators are having >> similar issues and if my work would be of use for community. >> >> I would like to ask translators and translation maintainers to fill this >> 7-or-less-questions survey: >> >> https://docs.google.com/spreadsheet/viewform?formkey=dFdSWjBndTNhVmxka1dGV2xxRmstWmc6MQ >> >> Disclaimer: I don't commit to writing such software. Unforeseen events >> can disrupt it. > > > I can see your point, that reporting these things are not as easy as they > could be. On the other hand, as Olav also said, I don't think it is worth > the overhead to develop another tool. Furthermore, (as I also wrote in your > survey) I'm not particularly interested in what you refer to as "drive by > bug reporting" and so, requiring users to register before they report a bug > helps to filter those out, though we do probably also filter to much. The Sugar Labs Translation teams use Pootle. I would tend to separate bug reporting into two categories 1) i18n issues (typos in English string, poor i18n practices, etc.) These need to go to the developer anyway and so the projects bug-tracker is typically best for that. Having a communication forum (typically an e-mail list like this one) where less tech-friendly team members can raise these issues for submission by a "bug-tracker aware" reviewer / team leader can bridge the i18n reporting gap fairly well and result in "better" (more actionable) bug reports for the developer. 2) L10n issues (poor translations, printf errors, etc.). Pootle has the capability of accepting "suggestions" that are not inserted directly in the PO file, but are maintained separately for acceptance or rejection via the Pootle UI. Depending on how you set the privs for the "drive-by user" (Pootle user "nobody") you can enable collection of "drive-by" string suggestions and have the accept/reject done by a registered user (or language admin). cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Bad translations of key names
On Thu, Mar 15, 2012 at 11:29 AM, Chusslove Illich wrote: >> [: Bastien Nocera :] >> For example: >> msgctxt "keyboard label" >> msgid "Page_Down" >> msgstr "Page_Down" >> >> When we clearly mention to: >> - translate the strings >> - Remove the underscores from the key names > > In spite of providing the comment, you are still breaking semantics of the > Gettext-based translation: msgid must contain that which the C/POSIX locale > user will see; if that is not sufficient as the message key, anything else > should be put in msgctxt. Hence, semantically proper messages could look > like this: > > msgctxt "keyboard label: Page_Down" > msgid "Page Down" > msgstr "" > > -- > Chusslove Illich (Часлав Илић) +1 I'm afraid I must agree that the issue is inadequate i18n, not poor L10n. Odd cases like this can be challenging for the developer to frame properly, but there is a certain duty not to violate the localizer's reasonable expectations if you want good results, no matter how you may comment it. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New Translation Language (Script) Request
http://live.gnome.org/TranslationProject/StartingATeam/ On Sat, Mar 17, 2012 at 3:14 PM, Eagle Burkut wrote: > Hello, > > There is a Uyghur (Arabic) translation team. I want to translate Gnome into > Latin based Uyghur. The language code is ug. > > How can I start a Uyghur (Latin) translation team and start translation? > Thank you. > > PS: > http://en.wikipedia.org/wiki/Uyghur_language > http://en.wikipedia.org/wiki/Uyghur_alphabet > > > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Diffing POT files
I frequently encounter situations where I am interested in comparing POT files that are closely related, but not 100% identical. Does anyone know of a tool or scriptable series of actions using Translate Toolkit modules (or other common text manipulation tools) where it is simple to determine the differences between two POT files (e.g. two versions of the same project at differnt points in time, etc.). I imagine something like a podiff or a pounique operation where there are two inputs (file1.pot and file2.pot) and the output might ideally be three files that represent the textual equivalent of a Venn diagram of these two files. file1-unique.pot msgids (still in a nice POT format) that are unique to file1 file2-unique.pot msgids (still in a nice POT format) that are unique to file2 file1-file2 common.pot msgids (still in a nice POT format) that represent the completely identical msgid overlap between file1.pot and file2.pot. This process should not permit fuzzy matching, which could lead to confusion. Does anyone know of such a tool? It would ideally be aware of PO file structure to treat string subunits of a PO file as a single "chunk" as opposed to a simple *nix diff which would be line-by-line. Alternatively, does any one have an "algorithm" employing Transalte Toolkit modules to achieve the same or similar result that could be turned into a shell script that involves minimal manual manipulation of the input of output files to achieve this sort of POT comparison result. TIA for any ideas or suggestions. cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Diffing POT files
On Thu, Mar 22, 2012 at 11:36 AM, Ask Hjorth Larsen wrote: > Not quite, but pyg3t contains a tool called gtcompare which will give > a qualitative overview of the differences between two files (useful > e.g. if there are conflicting changes and you want to see roughly how > bad things are) > > For example here's some output comparing before and after a recent > translation of mine: > > -- > askhl@mime:~/Downloads$ gtcompare old/gnome-disk-utility.master.da.po > gnome-disk-utility.master.da.po > Each file contains 425 msgids, and they are all identical. > > 0 messages remain untranslated. > 0 untranslated messages changed to fuzzy. > 5 untranslated messages changed to translated. > 0 fuzzy messages changed to untranslated. > 0 messages remain fuzzy. > 28 fuzzy messages changed to translated. > 0 translated messages changed to untranslated. > 0 translated messages changed to fuzzy. > 392 messages remain translated. > > There are no conflicts among translated messages. > --- > > Right now the script has no options. Maybe we should implement an > option to print the actual messages in specified categories. This > would be exceedingly easy I think. What would be a good syntax? > Something like: > > gtcompare --fuzzy2translated --untranslated2fuzzy file1 file2 > > (a bit long) > > Or: > gtcompare --print f2t,u2f file1 file2 > > (rather ugly) > > Any ideas? Well, you have 9 possible output categories, so I suppose defining which you want is going to be useful. In a simpler situation (three possible categories) the Translate Toolkit posplit command has a very simple syntax http://translate.sourceforge.net/wiki/toolkit/posplit posplit file1.po and the output is file1-translated.po file1-untranslated.po file1-fuzzy.po (be warned that the posplit script can be destructive of the input file, so perform it on a copy of your precious input file). I filed a bug on this and I think it is patched in the dev version, but I'm not sure if it is released. In the posplit case, you just get the three output files no matter which of them you are really interested in, but it is no great burden to discard the ones you do not want. The acceptability of that default might be less clear for gtcompare which would produce 9 output files (if modified to give you the files and not just the stats). On the other hand, if this "verbose" output is only invoked with an option flag, then you know what you are getting yourself in for when you run it with the option flag and that you could/would get 9 output files, so it would not violate user expectations. Possibly something simple like: gtcompare --verbose file1 file2 (result you get the 9 output files) I've installed PyG3T and I will play with it, if only because I love playing with widget collections to see figure out what workflows I can "pipeline" with a script, but I'm not sure thsi will get me where I want. gtcompare seems focused on looking at the msgstr (translations in the PO) and not the msgid (originals of the untranslated POT), but I will see what I can do with it anyway. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Special request for priority
I would like to ask the various teams to consider prioritizing WebKitGTK+ for translation http://l10n.gnome.org/module/webkit/ My reasoning is that we are developing a new version of our web-browser for Sugar (and the OLPC XO laptop) around WebKitGTK+ and because the web-browser is one of the places where you spend a lot of time, I believe the high visibility of these strings make them a high priority. Of course, it would be nice if the WebKitGTK+ devs would follow up on this bug https://bugs.webkit.org/show_bug.cgi?id=67580 or my duplication of it https://bugs.webkit.org/show_bug.cgi?id=81969 Thank you for your consideration. cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Special request for priority
On Thu, Mar 22, 2012 at 7:10 PM, Gil Forcada wrote: > Hi, > > Not to give stop energy, but I tried to pester the webkitgtk team during > the last Desktop Summit, but as the layout was not is completely > different from the usual GNOME modules, intltool and everything else > involved on that, seems to be not much cooperative. > > Still, more pushing from us will eventually make the switch turn and > have proper localization suport on webkitgtk, which I fully agree is > more and more important as days go by. Well, I'm staging a sit-in on #webkitgtk+ , if anyone wants to join me we can call it occupy webkit" :-) In all seriousness, it is quite important to us downstream at Sugar Labs, and as you probably know by now, I'm not shy about upstream-downstream dialog, so I did drop into their IRC channel today and bugged them about a few things. I got a response from mrobinson (see below) , I will hang out to see if I can follow-up. cjl hello, who manages the webkitgtk+ webpage? cjl http://webkitgtk.org/?page=contribute Really should list Translating as a way to contribute and reference the Damned Lies page http://l10n.gnome.org/module/webkit/ cjl Also it would be very nice if someone would address https://bugs.webkit.org/show_bug.cgi?id=81969 as it is a major blocker for translation (and therefore a major impediment to "market penetration" for WebKitGTK+ based tools. mrobinson cjl: Would switching to intltools fix all these errors? https://bugs.webkit.org/show_bug.cgi?id=45321 cjl mrobinson-afk: possibly switching to intltools would help, I can't be sure. On the Sugar Labs Pootle instance we do a lot with symlinks that works out okay. cjl mrobinson-afk: I would suggest posing the question to the gnome-i18n ML, where you will get a more informed opinion, I'm sure. cjl Part of it may also require editing the .skip file, but at this point it is so badly broken that experimentation can't disrupt it. cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Diffing POT files
On Thu, Mar 22, 2012 at 7:33 PM, Chusslove Illich wrote: >> [: Chris Leonard :] >> Does anyone know of such a tool? It would ideally be aware of PO file >> structure to treat string subunits of a PO file as a single "chunk" as >> opposed to a simple *nix diff which would be line-by-line. > > You could try Pology, http://pology.nedohodnik.net/. It contains an actual > PO diffing script, poediff, where what "PO diff" means is documented in the > user guide. But it will not produce what you described as the ideal output; > this is very simple, and can be produced by the attached script using > Pology library. > > -- > Chusslove Illich (Часлав Илић) Спасибо Часлав. I will install Pology and thank you very much for taking the time to provide the additional script, that was very kind of you. cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Special request for priority
On Fri, Mar 23, 2012 at 3:17 AM, Rudolfs Mazurs wrote: > C , 2012-03-22 18:00 -0400, Chris Leonard rakstīja: >> I would like to ask the various teams to consider prioritizing >> WebKitGTK+ for translation >> >> http://l10n.gnome.org/module/webkit/ > > Why isn't webkitgtk+ in at least gnome-extras category? > Good question. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Special request for priority
2012/3/23 Mario Blättermann : > Am 23.03.2012 09:46, schrieb Chris Leonard: >> On Fri, Mar 23, 2012 at 3:17 AM, Rudolfs Mazurs >> wrote: >>> C , 2012-03-22 18:00 -0400, Chris Leonard rakstīja: >>>> I would like to ask the various teams to consider prioritizing >>>> WebKitGTK+ for translation >>>> >>>> http://l10n.gnome.org/module/webkit/ >>> Why isn't webkitgtk+ in at least gnome-extras category? >>> >> Good question. >> >> > Good answer: Webkitgtk+ is not available from the GNOME Git repo. Those > modules are easy to maintain for translators, but supplying translations > for Webkitgtk+ is some more difficult. First, you have to translate it, > then you have to file a bug against Webkitgtk+, and one day (or some > days later) you get the answer from the maintainers that your po file > has been committed. In the meantime, your translation became outdated > again. Not that attractive for translators, and not that practical. Due > to these delays in the workflow, and due to that we don't have direct > commit access anyway, it would be odd to recognize Webkitgtk+ as a > "normal" module which could be assigned to a "normal" release set. Thank you for a thorough and informative answer, sadly "good" is a relative term, I might characterize it as a "realistic and accurate, but unfortunate" answer :-( It sounds to me like the solution will be as much "social engineering" as "software engineering" and will require some i18n/L10n evangelism in the WebKitGTk+ community. That obviously takes some time and is not necessarily "patched" that simply, but it is good to know the factors that are contributing to the low coverage rate of L10n for WebKitGTK+. I may be overly optimistic, but I tend to believe that software developers want the widest possible audience for their work and that i18n/L10n is an incredibly low-cost/high-impact route to expanding one's user base, so it is ultimately a matter of developing a "sense of enlightened self-interest" in the development community with regard to i18n/L10n issues. I appreciate the good wishes for my quixotic commitment to tilting at those particular windmills. [1], although I can certainly understand the reluctance of localizers to invest in a project that may not have been as responsive as it should be on i18n issues. Warmest Regards, cjl [1] http://en.wikipedia.org/wiki/Quixotism ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Small idea for Gnome Quarterly Reports
Petr Kovar regularly makes requests for input for Gnome Quarterly Reports like this one. http://mail.gnome.org/archives/gnome-i18n/2012-February/msg00038.html I looked at some older quarterly reports and I noticed the Membership Team provides some factoid stats snapshots (new members, etc.) and I would like to suggest that the i18n team consider something similar that could (hopefully) be pulled simply from the Damned Lies server. Some possible factoids Total registered teams Total registered team members Total hosted strings/words Total hosted packages Total completed strings/words Langs over some given % complete. Any given snapshot of these is more-or-less just a "death by PowerPoint" slide; however, over time mining the metadata that falls out from maintaining a system like Damned Lies is one of the few ways we have of quantifying our results in some potentially meaningful categories (recruiting localizers and completing strings). Analysis of a time series of such reports can indicate areas that might prompt corrective action (e.g. more active recruitment) in a way that is more than simply anecdotal. You would still want to report milestones reached, new initiatives/capabilities, etc. as is done now and the "stat box" need not be very large. Just a thought for consideration, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Special request for priority
On Thu, Mar 22, 2012 at 7:10 PM, Gil Forcada wrote: > El dj 22 de 03 de 2012 a les 18:00 -0400, en/na Chris Leonard va > escriure: >> I would like to ask the various teams to consider prioritizing >> WebKitGTK+ for translation >> >> http://l10n.gnome.org/module/webkit/ >> >> My reasoning is that we are developing a new version of our >> web-browser for Sugar (and the OLPC XO laptop) around WebKitGTK+ and >> because the web-browser is one of the places where you spend a lot of >> time, I believe the high visibility of these strings make them a high >> priority. >> >> Of course, it would be nice if the WebKitGTK+ devs would follow up on this >> bug >> >> https://bugs.webkit.org/show_bug.cgi?id=67580 >> or my duplication of it >> https://bugs.webkit.org/show_bug.cgi?id=81969 >> >> Thank you for your consideration. > > Hi, > > Not to give stop energy, but I tried to pester the webkitgtk team during > the last Desktop Summit, but as the layout was not is completely > different from the usual GNOME modules, intltool and everything else > involved on that, seems to be not much cooperative. > > Still, more pushing from us will eventually make the switch turn and > have proper localization suport on webkitgtk, which I fully agree is > more and more important as days go by. The attached transcript from #webkitgtk+ gives me some hope that a solution is being explored and that some long-pending submitted PO files have been committed. I will continue to follow up. cjl webkitgtk-L10n_IRC Description: Binary data ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Small idea for Gnome Quarterly Reports
On Mon, Mar 26, 2012 at 8:08 PM, Gil Forcada wrote: > > Care to create a page on live.gnome.org within the TranslationProject > with this factoids and a way to get them (i.e. the last one would be to > just go to [1] and see the number on the leftmost column) so that > whoever does the report has easy access on how to gather the data. > > A script that does that (or gets some of them) would be über cool > thought it can be done later on. As requested, I've created a stub of an article here: http://live.gnome.org/TranslationProject/GnomeQuarterlyReportStats and linked it from http://live.gnome.org/TranslationProject#Scripts_and_Statistics Additions and edits would be most welcome. Even more welcome would the some SQL-type script to pull these for the use of the poor quarterly report writer/editor. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Small idea for Gnome Quarterly Reports
Can bug #662454 be reproduced by anyone? In any event, I'm not suggesting that one rely on numbers blindly without validating them. It would be nice if you would note your concern on the wiki page (now that there is one) , but I suspect this table would not be produced / published until someone gets around to scripting it. cjl 2012/3/27 Daniel Mustieles García : > Just a comment to this... word statistics are not working properly in DL > [1], so maybe it should not be considered in the report > > I know there is a bug opened [2] for this issue, but it hasn't been solved. > > [1] http://l10n.gnome.org/vertimus/accerciser/master/po/es > [2] https://bugzilla.gnome.org/show_bug.cgi?id=662454 > > Cheers > > El 27 de marzo de 2012 02:08, Gil Forcada escribió: >> >> El ds 24 de 03 de 2012 a les 10:27 -0400, en/na Chris Leonard va >> escriure: >> > Petr Kovar regularly makes requests for input for Gnome Quarterly >> > Reports like this one. >> > >> > http://mail.gnome.org/archives/gnome-i18n/2012-February/msg00038.html >> > >> > I looked at some older quarterly reports and I noticed the Membership >> > Team provides some factoid stats snapshots (new members, etc.) and I >> > would like to suggest that the i18n team consider something similar >> > that could (hopefully) be pulled simply from the Damned Lies server. >> > >> > Some possible factoids >> > >> > Total registered teams >> > Total registered team members >> > Total hosted strings/words >> > Total hosted packages >> > Total completed strings/words >> > Langs over some given % complete. >> > >> > Any given snapshot of these is more-or-less just a "death by >> > PowerPoint" slide; however, over time mining the metadata that falls >> > out from maintaining a system like Damned Lies is one of the few ways >> > we have of quantifying our results in some potentially meaningful >> > categories (recruiting localizers and completing strings). Analysis >> > of a time series of such reports can indicate areas that might prompt >> > corrective action (e.g. more active recruitment) in a way that is more >> > than simply anecdotal. You would still want to report milestones >> > reached, new initiatives/capabilities, etc. as is done now and the >> > "stat box" need not be very large. >> > >> > Just a thought for consideration, >> > >> > cjl >> >> Great idea! >> >> Care to create a page on live.gnome.org within the TranslationProject >> with this factoids and a way to get them (i.e. the last one would be to >> just go to [1] and see the number on the leftmost column) so that >> whoever does the report has easy access on how to gather the data. >> >> A script that does that (or gets some of them) would be über cool >> thought it can be done later on. >> >> We have to honor our favorite application name :) >> >> Cheers, >> >> [1] http://l10n.gnome.org/releases/gnome-3-4/ >> >> >> -- >> Gil Forcada >> >> [ca] guifi.net - una xarxa lliure que no para de créixer >> [en] guifi.net - a non-stopping free network >> bloc: http://gil.badall.net >> planet: http://planet.guifi.net >> >> ___ >> gnome-i18n mailing list >> gnome-i18n@gnome.org >> http://mail.gnome.org/mailman/listinfo/gnome-i18n > > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What is the license of GNOME Commit-Digests?
Jiro, I would suggest asking the author of that blog, Frederic Peters. cjl On Thu, Mar 29, 2012 at 11:18 PM, Jiro Matsuzawa wrote: > Hi all, > > I will translate the GNOME Commit-Digests [1] for Japanese users and > developers. > But I'm not sure what is their license. > Can I translate them? > > Thank you in advance. > > [1] http://blogs.gnome.org/commitdigest/ > > -- > Jiro Matsuzawa > E-mail: > jmatsuz...@src.gnome.org > matsuzawa...@gmail.com > GPG Key ID: 0xECC442E9 > GPG Key Fingerprint: E086 C14A 869F BB0E 3541 19EB E370 B08B ECC4 42E9 > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Mistakes in doc translations
On Sat, Apr 21, 2012 at 1:40 PM, Shaun McCance wrote: > On Thu, 2012-04-19 at 13:34 +0200, Chusslove Illich wrote: >> > 4) Due to workflow, we don't have a baseline commit to reference. >> > [...] >> > (4) is a serious problem. git is really smart, and has a number of merge >> > strategies that I can only describe as "magic". But they don't work if you >> > bypass version control. >> >> For this I have no practical idea how to solve. Other than locking workflow >> being the norm, translators are frequently pointed to web-based solutions >> instead of version control (so that they don't get scared off by the >> process). Then, it is not unusual for regular translators not to have commit >> access, which would extremely odd for regular programmers (or documenters, >> right?). > > The beauty of git is that everybody can commit, even if they can't > push their changes to git.gnome.org. We start docs people off using > git very early. We have them commit their changes as normal and send > git patches to somebody with an account on gnome.org. > > I know learning version control first is a hurdle (and git especially > so), but I also think it's a valuable skill that will save you time > and again going forward. And with distributed version control, we're > no longer tied to who has an account where to get those benefits. > I would suggest that going to Pootle is a good step short of moving to a git workflow and far more friendly to locaiizers. I run a substantial Pootle instance, not quite as Gnome, perhaps, but still hosting tens of thousands of words and strings on over 100 languages. cjl cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [Gimp-developer] Translating GIMP from GIMP master (is wrong)
On Wed, May 9, 2012 at 4:41 AM, Michael Natterer wrote:
> You are right, generating a new template results in 62 strings.
>
> There seems to be a bug in intltool-update --pot that only
> extracts strings which immediately follow a '(', so
>
> (_"foo" ends up in the template
>
> but
>
> _"foo" doesn't.
>
> At least that's the pattern I found when looking at the pot file
> and the scheme source files.
>
> To the folks on gnome-i18n@gnome.org: did you ever hear of this
> issue? Can you investigate it? I'm sure there are more i18n experts
> on gnome-i18n@gnome.org than on gimp-developer-list ;)
Please review this bug, which details the probable cause (ignoring
.scm files?) for GIMP script-fu only having 61 strings instead of
600-odd.
GIMP missing menu translations
https://bugs.launchpad.net/intltool/+bug/986897
They are using a manual workaround on Launchpad for Ubuntu (comment #8)
There is a also comment that this change may have introduced the issue:
http://bazaar.launchpad.net/~intltool/intltool/trunk/revision/722
I came across this while searching for an answer to why WebKitGTK+ POT
generation is munged up. It apparently can most easily be fixed by
addressing this intltool ticket.
There's no way to specify where's the po directory if it's not on topdir
https://bugs.launchpad.net/intltool/+bug/823217
If you use Launchpad, please feel free to click the "this bug effects
me" link on this bug. I'm hoping for some action on it. Good luck
getting intltool to not mangle the GIMP script-fu POT generation.
cjl
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Merging translations from Ubuntu, keeping fuzzy strings
On Sun, May 13, 2012 at 11:01 AM, Chris Leonard wrote: > On Sun, May 13, 2012 at 6:15 AM, Åsmund Skjæveland > wrote: >> I've received some Ubuntu translations and I'm wondering how to best >> merge them. The up-to-date translated strings look fine, but fuzzy >> strings in the gnome PO file are untranslated in the Ubuntu PO file, and >> also in the merged PO file. >> >> For example: >> >> In http://l10n.gnome.org/vertimus/gedit/master/po/nn , the word >> "GTK_WRAP_CHAR" is present in some fuzzy strings in the gnome PO file, >> but those fuzzy strings are not in the Ubuntu file or the merged file. >> Instead, the updated msgids are untranslated. Also, the gnome file has >> history/previous version of the string, but the ubuntu file and the >> merged file doesn't have the previous string included. >> >> Is there some merging trick that preserves fuzzies? > > One trick I use when trying to compare two closely related PO files is > to place the files in a folder and then use the pocompendium tool from > Translate Toolkit. > > http://translate.sourceforge.net/wiki/toolkit/pocompendium > > pocompendium will highlight the differing strings by making them into > fuzzy, pocompendium flagged strings. > > Reviewing the output file with Virtaal > > http://translate.sourceforge.net/wiki/virtaal/index > > It is quite easy to select pocompendium flagged strings. > > This preserves fuzzy flagging (from either file) and adds fuzzy > flagging where there is a conflict. This maximizes the "human review" > element, which IMHO is all for the good. It is not necessarily ideal > for creating a final uploadable merged PO, but it does focus human > attention to the strings that need review. > > cjl A variation of the pocompenduim trick is that it can be run on a large collection of PO files in a directory. I do this to QA conflciting translations of common strings across a language. 1) Collect all the PO files in a directory. 2) run pocompendium producing a single output.po file 3) Make and preserve a copy of the output.po file (because the next step is destructive of the input file). 4) Run posplit on the output.po file. this destroys output.po (a bug fixed in trunk, I think) and produces three files, one translated, one untranslated and one fuzzy (also containing the fuzzy pocompendium flagged strings that represent conflicts). 5) Review the pocompendium flagged strings in the fuzzy.po file for conflicting translations. 6) Bring those translation conflicts to the attention of a native speaker for review (in context of each PO file where they appear to account for msgctext comments). I recommend this as an approach to anyone concerned about maintaining consistency of terms across a collection of Po files in their language. I've tried the poconflicts tool from Translate Toolkit, but I find the out put of the above easier to review. Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GCompris needs a translation update
On Wed, May 16, 2012 at 11:20 AM, Bruno Coudoin wrote: > Hi, > > We have set the 3rd of June as the new release date for GCompris. > > It will be mostly a maintenance release, a good opportunity to > update the translations if its not already done. > > Also, you can refer to this page for additional instructions: > http://gcompris.net/wiki/Translation_addons > > Thanks for your help, > > Bruno. Dear Gnome L10n teams, I would like to add my voice to Bruno's in asking for your help with completing the GCompris strings for the upcoming release. http://l10n.gnome.org/module/gcompris/ At Sugar Labs, we give GCompris games a light coat of Sugar and re-package them as "Activities" for deployment on OLPC XO laptops (and the other ways of tasting Sugar). http://wiki.sugarlabs.org/go/DocumentationTeam/Try_Sugar The GCompris games are very popular with deployments and any assistance with making these learning games available in these children's native languages would be much appreciated and a wonderful contribution to education. Warmest Regards, cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
AbiWord L10n
Dear Gnome Localizers, The AbiWord team is nearing a 3.0 release (no firm date set),, but the e are a number of languages that could use some additional L10n work. Any contributions you could make to this fine FLOSS word processor would be greatly appreciated. http://www.abisource.com/ Sugar Labs is hosting AbiWord L10n now in recognition of the contributions of the AbiWord team to developing the Write Activity for Sugar and the fact that OLPC distributes AbiWord by default on the Gnome boot-side of their Sugar-Gnome dual-boot images. please work on abiword.2.9.dev.po http://translate.sugarlabs.org/projects/AbiWord/ Warmest Regards, cjl Sugar Labs Transslation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translator abuse?
On Mon, Jun 18, 2012 at 6:56 AM, David Woodhouse wrote: > The OpenConnect VPN client exports a library, libopenconnect, which > handles the fun part of communicating with the server to authenticate. > > This is used from the NetworkManager authentication dialog. > > However, The OpenConnect package lives outside GNOME git and its > translations are handed in Transifex. Its translation coverage is fairly > poor. > > This means that when you use NetworkManager-openconnect in a language > which is fully supported by GNOME, you *still* get to see untranslated > strings where they come from OpenConnect itself. > > I'm pondering "artificially" importing the translatable strings from > OpenConnect into NetworkManager-openconnect, so that they get translated > by the GNOME translation teams and the GNOME user experience for these > languages is much better. > > However, this is technically a trick — I'd be importing strings from > another package *outside* GNOME, which aren't used directly from the > GNOME package, only to "harvest" the translations and put them back into > the non-GNOME package. > > Would that be considered acceptable? As a downstream that faces this sort of issue more frequently than Gnome probably does given the Gnome position in the software stack, I have tried to resolve similar issues in a variety of ways (as Translation Team Coordinator of Sugar Labs / OLPC), with differing levels of success. In descending order of success from most successful to least successful. 1a) Obtain buy-in from my org (Sugar labs Oversight Board and our parent fiscal sponsor SFC) that offering hosting on our Pootle instance was a wise and acceptable use of our resources in a particular case (AbiWord). Engaging with the AbiWord community and working over time to gain their trust and convince them of the superiority of the hosted solution being offered over existing L10n workflow (complete and mail PO files) and advantages of accessing a larger pool of localizers. Continuing engagement with high levels of responsiveness to AbiWord localizers to maintain trust and smooth the transition. Results: Very successful, win-win-win achieved. (OLPC AbiWord users / AbiWord devs / AbiWord localizers). Results measurable by higher levels of completion and expanded number of languages. http://translate.sugarlabs.org/projects/AbiWord/ Compare stats for 2.8 (pre-Pootle) to 2.9 (post-Pootle) http://www.abisource.com/contribute/translate/ 1b) We have had this arrangement with eToys for a long time, so I am not counting them, but their stuff lives in it's own SVN repo (that we commit to via a special user:pootle given commit privs). POT updates are coordinated periodically. Essentially we share the Pootle instance and the localizers as an ICT educational community resource of the greater Sugar Labs / OLPC / eToys community. 2) Engage with a friendly upstream (Gnome) from whom we inherit a LOT of L10n bits, make polite requests about how to better coordinate, get a very helpful response with the creation of a special "OLPC Release Set" that allows us track our upstream L10n bits and makes it easy for our localizers to identify those bits we use (thanks Claude). Hopefully, also makes it easy for willing upstream localizers to prioritize our L10n bits, if so inclined, as OLPC distributes dual-boot Sugar/Gnome builds providing a fully functional, but somewhat simplified Gnome desktop to millions of kids as an alternative to Sugar UI. http://l10n.gnome.org/releases/olpc/ Results: Hard to measure specifically. Success metrics would include evidence that our localizers were working upstream, or that upstream localizers choose to prioritize our bits. My sense is that this is overall an elegant solution for Sugar/OLPC and we do provide a "trail of breadcrumbs" that our localizers can follow upstream easily, which would benefit Gnome. There are inherent benefits to collaborative / cooperative information exchange and smoothing project to project migration of contributions, but I really can't put hard numbers on how well it has worked out. It is clear that it is a no-lose situation for all parties, so I'll declare it a win. :-) 3) Provide simple "trail of breadcrumbs" for localisers to follow from our L10n infrastructure to other upstream hosted L10n (Gnome, Translate Project, Fedora Transifex, Scratch Pootle instance) for packages we pull. This is done by virtue of creating a dummy project containing dummy PO files that serve the function of tracking tickets. http://translate.sugarlabs.org/projects/upstream_l10n/ The PO is hand crafted (with a spreadsheet) to contain a developer's comment with a link to the upstream L10n hosting for the package and tracking is achieved by dummy "translation" of that package string with "Completed on date X)". Results: Again hard to measure, but I am not that optimistic. Frankly, a number of our localizers find this confusing and end up providing a literal translation instead of follow
Kyrgyz locale
On Fri, Jul 27, 2012 at 6:04 PM, Chingis Jumaliev wrote: > Where can I change the order of date in the calendar, I want to make > like this: year month day week, from big to small. > Also I want to change the old translations of months into kyrgyz. Dear Chingis, I am only making a guess, but I think you are asking about how to make changes in the glibc locale for Kyrgyz. http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/ky_KG;hb=HEAD You would need to file a bug on the localedata component at: http://sourceware.org/bugzilla/enter_bug.cgi?product=glibc cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: No Subject
On Sat, Jul 28, 2012 at 5:13 AM, Chingis Jumaliev wrote: > Yes, I mean the month names. They were written in Russian by Timur, > but we have our own Kyrgyz month names. And I want to fix this > mistake. Chingis, Are these the months names you are currently seeing? январь февраль март апрель май июнь июль август сентябрь октябрь ноябрь декабрь If so then they are probably coming from the glibc locale. Submitting corrections to glibc locales can be technically challenging as they must be submitted with conversions into Unicode code points. Claude Paroz has developed a tool to make this easier, but glibc locale files still remain a little difficult to work with. I would be happy to work with you to submit a patch to the ky_KG glibc locale (we collaborate on this off-list by direct e-mail). I've had some experience in working on glibc locales and if you will please complete the PO file called "glibc-helper.po" in the following project on tyhe Sugar Labs Pootle server: http://translate.sugarlabs.org/ky/Sandbox/ It will be a start on developing a patch for the existing glibc locale and when we have the patch compiled, I will work with you to submit it to the proper place and process to have it considered for inclusion. The glibc maintainers generally require some solid evidence before making changes in existing locales, so if you could cite a government web-site or online newspaper that uses the months names you are proposing that will be an important piece of supporting information to include with the patch we will work on developing. Regards, cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Kyrgyz months
On Sat, Jul 28, 2012 at 12:26 PM, Chingis Jumaliev wrote: > OMS, the government and the newspapers uses only Soviet month names, I > hate them. So I can only show a scanned page from the Russian-Kyrgyz > Dictionary of Yudakhin (attached). Anyway, the Kyrgyz months are used > in schools, in which I studied. Dear Chingis, It seems that you have a number of differences of opinion with the currently listed Kyrgyz Team Coordinator, Timur Jamakeev. This list is not really the place to resolve those issues because no one else here seems to be a Kyrgyz speaker, and so they will not be not able to offer informed opinions on the issues you raise. I strongly suggest that you follow GNOME's procedures to address your concerns. You should read more about those procedures on the Translation Project wiki to become familiar with them. https://live.gnome.org/TranslationProject If the Kyrgyz team coordinator is not responsive to your requests or is no longer active, you can request the opportunity to be the lang-ky team coordinator yourself; however, the Gnome procedure is to give the previous Team Coordinator the opportunity to address your concerns. As for the glibc locale issues you have raised, this list is not the correct place to raise them. They should be addressed by filing a bug (ideally with a patch) in the bug-tracker. I have offered to work with you to file a patch, but I do suggest that we do this off list, because it is not of general interest. Having this discussion on-list is not going to achieve any results, only by filing a bug and patch will you have a chance of seeing the changes you request in the glibc locale information. I am also willing to work with you so that you can modify the glibc locale file that you use locally while waiting for a patch to be accepted. If you would like to begin working on productive avenues of addressing your concerns, please write to me privately and I will help you to follow the necessary procedures for developing and filing a glibc locale ticket. Posting information about glibc locales to this list will not accomplish anything useful. Regards, cjl Sugar Labs Translation Team Coordiantor ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposing 'gnome-initial-setup' for translation
On Mon, Jul 30, 2012 at 10:41 AM, Jasper St. Pierre wrote: > We'd like to have initial setup for 3.6. Right now a few random people > have found it through the new modules list, but before it's too late, > I'd like to have it added to Damned Lies. > > I don't quite know what the process is, and couldn't find any page on > the wiki of what to do, so I'm just writing here. Jasper, I do not see 'gnome-initial-setup' listed in the Damned Lies list of modules: http://l10n.gnome.org/module/ At the bottom of that page, there is a statement: "If anything should be changed on this page, please submit a bug report." linking to https://bugzilla.gnome.org/enter_bug.cgi?product=damned-lies&component=l10n.gnome.org I would imagine that filing a bug would be the best method of reporting this issue. Once the 'gnome-initial-setup' module is listed on Damned Lies, it can be added to the proper "Release Set" as you request. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposing 'gnome-initial-setup' for translation
On Mon, Jul 30, 2012 at 2:23 PM, Gabor Kelemen wrote: > 2012-07-30 19:07 keltezéssel, Jasper St. Pierre írta: > > >> Not sure how I missed it. Filed bug >> https://bugzilla.gnome.org/show_bug.cgi?id=680854. >> > Done: http://l10n.gnome.org/module/gnome-initial-setup/ No worries Jasper, it looks like Gabor also associated master branch with the Gnome 3.6 Release Set, s oyou should be all set. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GUADEC's GTP BoF summary
On Wed, Aug 1, 2012 at 7:00 AM, Gil Forcada wrote: > Wow, that's quite a lot of acronyms :) > > Anyway on topic... > > As some of you have already seen we (all translators and GTP Coordinator > members) that were at this year's GUADEC meet on 30th of July all day > long to discuss about the 14 topics listed on the wiki page about the > meeting: > https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012 Thanks for the summary of the discussion for those of us who could not attend GUADEC. > Please bear with us, as the notes maybe do not make much sense for > someone not on the BoF. We all (BoF attendees) will try to clean them up > and maybe it would make sense to send a mail (even if that will be 14 > mails) on this mailing list explaining the idea of each of them. > > This way we can add every one of you on the loop of the current > activities and motivations behind all this 14 points. There does not appear to be a Discussion page on the wiki, so I am hoping that comments on this list about individual elements of the 14 follow-up actions points will be welcomed. Otherwise, please specify an alternate feedback mechanism. Item: Making guidelines As Gil previously mentioned, it is indeed great to see new languages coming to Gnome. https://mail.gnome.org/archives/gnome-i18n/2012-July/msg00118.html I went looking the documentation on the wiki that offered general advice to new language teams on how to prioritize their work on Gnome and the best guidance I've found is this: https://live.gnome.org/TranslationProject/LocalisationGuide?highlight=%28CategoryGnomeI18n%29#Choosing_the_first_packages_to_translate I think some more extensive guidance on prioritization would be very helpful. Consider the daunting scope facing a team first looking at Gnome L10n: 41K 3.6 release set 3.3K External Dependencies (GNOME) release set 11K GNOME-Office Productivity Applications 4.2K GNOME Infrastructure 10K GIMP and Friends 10K Extra GNOME Applications (stable) ~80K total At the risk of sounding self-serving, one might consider suggesting the OLPC Release set as a starting point. ~30K OLPC Release set (drawn from across the above Release Sets on the basis of providing a minimalist, but fully functional Gnome boot on OLPC OS images.) Admittedly this is not perfect. Some clearly lower priority items are included. 4.2K from GIMP and Friends 6.8K from libg-weather 5.8K from gnumeric which do not necessarily merit prioritization in the overall scheme of things. Skipping these would give an OLPC designated set in the 13.2 K range covering a lot of highly user-visible packages. Item: Just reaching out to local communities I personally think the concerns about perceived "poaching" of localizers is overblown and even a little insulting to localizers. Localizers are free agents and work on what they choose, when they choose. In my experience, localizers are (for the most part) characterized by language loyalty more than package/distro loyalty. Another option which carries no "poaching" stigma is to promote Ui string harmonization across orthologous packages (packages performing the same or similar functions in different distros). For example, why do Gnuchess, glchess from gnome-games and Knights from KDE have so few strings in common? Surely the basic text to describe a chess game could be harmonized to a greater extent and shared across these packages whose primary differentiation has to do with back-end chess engine support. Newspaper chess columns (for those of you who still look at print media), has standardized on a short and frankly ugly alphanumeric terminology for describing chess moves and entire games in a compact fashion. Surely, we can do nearly as well. There are also clear opportunities in word processors and other commonly implemented packages (networking apps, etc.). How many different strings does the FOSS world really need to describe indentation and other common typesetting functions? English searches in open-tran.eu will identify plenty of chances to reduce string variability (and increase consistency) across projects, some of which might even be appealing to developers if offered in the context of more rapid or broader L10n coverage. Item: glibc locales. I definitely have some strong opinions in this area, but I'll table them for now as this message has rambled on long enough. These are just a few thoughts of my own on some the agenda topics raised. Warmest Regards, cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: BoF item 4/14: Splitting modules
On Fri, Aug 3, 2012 at 1:46 PM, Johannes Schmid wrote: > Hi! > > See https://live.gnome.org/TranslationProject/SplittingModules > > Overall we wanted to base the "Supported language" status on having > translated at least 80% of Core, Core Apps, Extra Apps and > Accessibility. Furthermore, we *might* want to create a "Basic Support" > status for having translated Core and Core Apps to give more motiviation > to small teams. > > We still need feedback if there are any UI strings in the "Libraries" > section that are shown to the user. (Excluding cryptic error messages > and properties displayed in glade). Johannes, One of the main reasons I've mentioned the "OLPC Release Set" http://l10n.gnome.org/releases/olpc/ as a potential starting point for localizers is that it represents the Gnome packages that are pulled down by OLPC (typically via Fedora RPM repos) to create the Gnome side of the Sugar/Gnome dual-boot OS image, as well as a few Gnome core infrastructure modules that lay a little deeper in the stack of what is a fairly minimalist GNU/Linux Fedora spin. It's value as a point of comparison is not so much that it is want is needed for an OLPC XO laptop, but rather that it is a module collection that has been culled down by intense size pressures (one GB total storage on an XO-1) and therefore is one specific example of a "minimal" set. I've done my best to keep the packages displayed in the OLPC Release Set current by going through the packages.txt file in OLPC releases as they become available, a pending major release by OLPC is complicating this a little at the moment. I should explain that at the present, time while there is an ongoing transition from GTK2 to GTK3 in the Sugar / OLPC OS stack, I have chosen to only point to the GTK3 master branch versions of packages. This release set is intended to be more forward-looking in terms of L10n needs/wants and not necessarily about back-filling translations on existing releases, although the reality of the situation is that an OLPC release will likely be one or more release cycles back from Gnome master when it goes out the door given that it largely draws from Fedora RPM repos and lags the Fedora release cycle. Taking a look at the libraries (or other packages) included in the OLPC release set might give you some ideas about what it might be worth including in a priority L10n target set. You will need to take into account that given it's focus on children in the educational setting, the inclusion of things like gcompris are driven because they are educational games and not because they are needed to make a minimal Gnome desktop sign and dance. Just a thought for your consideration. Consider it one downstream's very-specific POV as measured by the packages pulled from Gnome. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Best way to format a name string in Folks
On Sat, Aug 4, 2012 at 9:34 AM, Gabor Kelemen wrote: > Hi Laurent > > 2012-08-04 10:18 keltezéssel, Contzen Laurent írta: > >> Hello, >> >> I'm currently adding a new display-name property in FolksIndividual as >> discussed in bug #651672 >> (https://bugzilla.gnome.org/show_bug.cgi?id=651672). One of the possible >> values we'd like to set this value to would use the given_name and the >> family_name of the contact. Currently, I'm simply doing >> >> var name = structured_name.given_name + " " >> + structured_name.family_name; >> >> which outputs a string containing exactly "$given_name $family_name". >> >> Is this the best way of doing this or should, for example, the string >> format be translatable? >> > > This should be translatable. > > For example, the standard name order in Hungarian is $family_name > $given_name, so your solution would not work for my language and for a few > more, see: http://en.wikipedia.org/wiki/Name_order#Name_order > > Probably "%s %s" with a comment about their meaning and how to switch the > order is enough, like: > > Translators: first %s is the given name of the contact, the second %s is the > family name. To change the order, use "%2$s %1$s" I think if you are going to use variable names as Gabor suggests, I would go beyond using the simplest string name token "%s". With mor ethan one such token in a translatable string is less than ideal, I would suggest something like %(givenname)s %(familityname)s. Yes, it is true that this will inevitably result in some printf errors when localizers mistakenly translate what is inside the parenthesis, but these are easy to catch (pofilter printf flag) and easier to fix (just change the variable name back to English). I'm not convinced that this format will result in any more errors than using the simplest tokens and expecting localizers to add the proper numbering as suggested by Gabor. My own point of view on this is that I find it frustrating when developers to ask a localizer to do a job that the glibc locale should be capable of addressing all on it's own. Translating Day and Month names should be banned in PO files :-) There is in fact an entire section in glibc locales called LC_NAME in the glibc locale that has a field for Name format (name_fmt) as described below. My argument is that develoeprs should leverage the information content of the glibc locale to the greatest extent possible, that is after all the primary purpose of having glibc locale files. cjl Sugar Labs Translation Team Coordinator >From Claude Paroz's excellent Locale Helper web-app http://lh.2xlibre.net/values/name_fmt/ LC_NAME Name format (name_fmt) Define the appropriate representation of a person’s name and title. The operand consists of a string, and can contain any combination of characters and field descriptors. In addition, the string can contain field descriptors defined below. %f Family names. %F Family names in uppercase. %g First given name. %G First given initial. %l First given name with latin letters. In some cultures, eg on Taiwan it is customary to also have a first name written with Latin letters, although the rest of the name is written in another script. %o Other shorter name, eg. "Bill". %m Additional given names. %M Initials for additional given names. %p Profession. %s Salutation, such as "Doctor" %S Abbreviated salutation, such as "Mr." or "Dr." %d Salutation, using the FDCC-sets conventions, with 1 for the name_gen, 2 for name_mr, 3 for name_mrs, 4 for name_miss, 5 for name_ms. %t If the preceding field descriptor resulted in an empty string, then the empty string, else a . Each field descriptor may have an after the <%> to specify that the information is taken from a Romanized version string of the entity. An initial is any string, normally consisting of one letter and a punctuation mark; the Dutch "IJ" is an example of a two character initial. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: BoF item 5/14: glibc locales
Digging back to an old post I meant to reply to earlier. On Thu, Aug 2, 2012 at 4:04 PM, Gil Forcada wrote: > Hi all, > > As I said in previous mails, let this mail be a kickstart for giving > feedback about the items that are defined on > https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012 > > In this mail please give feedback about the glibc locales item. > > Cheers, > -- > Gil Forcada Quoting from: https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012 glibc locales Background: Now and then new translation projects appear on GNOME i18n mailing list. Sadly most of them needs to create a glibc locale, which is both a tedious and a complex process in itself. Having some expertise and knowledge about how the glibc locale does work, knowing who can help on both creating the locale and getting the locale on glibc will greatly help those new languages. Bullet points: we need to gather some expertise on it Gil, This is an issue very near and dear to my heart. By the nature of the user communities that Sugar Labs seeks to serve, we are often involved in assisting with the development of glibc locales for languages or regions that are not currently represented in the glibc project. I have taken it upon myself to reach out to people needing assistance with glibc locale creation (usually off-list, but sometimes on-list). In general, I am happy to continue to perform this sort of orientation, consultation and hand holding on the arcane art of developing glibc locales. For example, the initial message about nhn_MX, followed by a few friendly off-list e-mails: https://mail.gnome.org/archives/gnome-i18n/2012-August/msg00041.html Has produced this ticket: http://sourceware.org/bugzilla/show_bug.cgi?id=14501 I think we need to acknowledge that there are bigger problems with regard to glibc locales, in particular their submission and correction workflow, than the occasional message to this list and even the technical complexity of creating one. Claude Paroz has done excellent work on facilitating the constructing the obscure Unicode code point required format for glibc locales. http://lh.2xlibre.net/locales/ However, I think the core issue with glibc locales as it relates to i18n/L10n is the fact that the responsiveness of the glibc team to locale-related tickets is in need of real and immediate improvement. Take a look at the list of pending localedata bugs filed against the glibc component. http://sourceware.org/bugzilla/buglist.cgi?product=glibc&component=localedata&resolution=---&list_id=5916 I have submitted locale patches that are obvious (even to an English-only speaker), indisputably correct and entirely uncontroversial that have been sitting in the queue for months with out attention: http://sourceware.org/bugzilla/show_bug.cgi?id=13950 Similar delays are encountered by people who have submitted new glibc locale files. This is a huge barrier to entry for new languages and frankly it is all too easy to kill the momentum of a new language effort. It is critical to work with new language efforts while the enthusiasm is high, so that it can be maintained by visible signs of progress. We all know that the glibc bug-tracker has long had a (well-deserved and notorious) reputation as a very unfriendly place to interact with the Gnome project. What is needed is someone on the glibc team that has a focus purely on the localedata and a modicum of basic social skills that is willing to deal with newcomers to the Gnome world in a welcoming fashion. In addition, ideally something like the work that Claude has done on his Locale Helper needs to be turned into a web-app like the CLDR locale submission process Survey Tool and integrated into Gnome's SOPs for locale submission. Improving the "customer service" ethos of the glibc locale submission process is essential and long overdue, facilitating it with a user-friendly tool would be icing on the cake. Just my thoughts. What are yours? cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: BoF item 3/14: Outreach
On Thu, Aug 2, 2012 at 4:04 PM, Gil Forcada wrote: > Hi all, > > As I said in previous mails, let this mail be a kickstart for giving > feedback about the items that are defined on > https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012 > > In this mail please give feedback about the Outreach item. > > Cheers, > -- > Gil Forcada GUADEC 2012 BOF follow-up https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012#Outreach Outreach plan https://live.gnome.org/TranslationProject/Outreach . . . quoting from link above Just reaching out to local communities Talk with marketing team about marketing materials to encourage local languages to do translations. If other langs have teams in LibreOffice and KDE, talk about GNOME translation. This is politically sensitive, because this could look like poaching. Better to contact translation coordinators and downstream translators (particularly Ubuntu translators). . . . There are many good reasons to pursue closer coordination and cross-polination with the LaunchPad-based Ubuntu L10n community, in particular. They are a large community with a wide variety of languages and they co-host a large number of Gnome originated packages. Significant levels of (DL and LP) "dual citizenship" already exist. I would like to make a couple of specific proposals about methods that could be pursued in the outreach effort with regard to the LP-based Ubuntu L10n community. 1) Provide a DL - LP cross mapping I suggest the creation of a "LaunchPad co-hosted Release Set" on the Damned Lies server, similar in function to the "OLPC Release Set" that was created by Claude Paroz and that I maintain. http://l10n.gnome.org/releases/olpc/ The purpose of this is to provide a quickly visible set of summary statistics and quick links to packages that are hosted on both the Damned Lies server (DL) and Ubuntu LaunchPad (LP). Ideally, this release set should be maintained by someone involved in coordinating Ubuntu translation efforts on LP (at an overall Ubuntu level, not necessarily at a language-specific level). What would this accomplish and why is it a win-win? DL-based localizers (particularly those with an Ubuntu affinity) can easily prioritize Ubuntu dependencies for completion in their DL work. LP-based localizers can easily identify opportunities to upstream their work to DL and thereby reach a larger audience (e.g. other Gnome-using distros) and leverage their efforts more widely. This should particularly appeal to "language loyal" localizers, although I'm sure the notion of sharing "Gnomey ngoodness" will also motivate some. LP-based localizers can benefit from working on the DL master branches of packages as a means of "pre-localizing" packages that, when released as stable, will make make their way into LP and Ubuntu. Even though the Ubuntu focus may be on an older stable release, by working on a DL master branch, they are "getting ahead of the game", which will allow them more time to focus on Ubuntu-specific strings that change within an Ubuntu release cycle. I have attached a spreadsheet that is a first pass at mapping Gnome DL project pages to Ubuntu (Quantal) LP project pages. I have not done a drilldown to the specific release level. I think the focus should be on master as the issues of version lag are pretty much a wash after a few cycles as long as you focus on the master branch. The one exception is where it looks like LP tracks a Gnome2 version separately from a Gnome3 version, in those cases, I've left a blank cell following the Gnome package name in the first column and added both links in the LP column. I did this match by scanning: http://l10n.gnome.org/module/ and https://translations.launchpad.net/ubuntu/quantal/+templates I would welcome it if someone else would review these links and the spreadsheet to correct any mistakes and add anything I may have missed in this quick and dirty review. BTW, this sheet is more-or-less the start of the "LaunchPad co-hosted Release Set" list. 2) Exchange diplomatic delegations and credentials. Having a formal (or informal) back-channel for DL coordination team to LP coordination team communications would be very useful. This is not meant to be the only channel of communications and does not replace filing tickets in each others bugtrackers, etc., but it could be very useful for planning higher-level joint activities or drawing focused attention to specific issues of mutual interest. One such example might be: To her Excellency the Ambassador Plenipotentiary of the Empire of Ubuntu, Kubuntu, Edubuntu and outlying islands from the Legation of the People's Republic of Gnome. "Hey you folks have a lot of African language projects that don't have glibc locales yet. Can we work together to fix that?" Regards and Felicitations. Your Loyal Servant, etc. etc. etc. 3) Address identifiable language team level opportunities for better cooperation (specifically, weak uplinks from LP to DL) I
Re: BoF item 3/14: Outreach
BTW, this page: https://launchpad.net/gnome may have a better (or at least larger) list of Gnome associated projects in LaunchPad than my spreadsheet. I focused only on those packages included in Quantal, while this list also includes older packages, some of which may be deprecated though. In any event, I would suggest that language team leaders may want to run down the links on that page and check to see if there may be some L10n effort present on LaunchPad that has not been upstreamed to your languages on DL. Reaching out to the LP team if you find that situation, might improve the "weak uplink" situation and result in less duplication of effort by your DL team. cjl On Fri, Aug 31, 2012 at 4:24 PM, Chris Leonard wrote: > On Thu, Aug 2, 2012 at 4:04 PM, Gil Forcada wrote: >> Hi all, >> >> As I said in previous mails, let this mail be a kickstart for giving >> feedback about the items that are defined on >> https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012 >> >> In this mail please give feedback about the Outreach item. >> >> Cheers, >> -- >> Gil Forcada > > > GUADEC 2012 BOF follow-up > https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012#Outreach > > Outreach plan > https://live.gnome.org/TranslationProject/Outreach > > . . . quoting from link above > > Just reaching out to local communities > > Talk with marketing team about marketing materials to encourage local > languages to do translations. > > If other langs have teams in LibreOffice and KDE, talk about GNOME > translation. This is politically sensitive, because this could look > like poaching. Better to contact translation coordinators and > downstream translators (particularly Ubuntu translators). > > . . . > > There are many good reasons to pursue closer coordination and > cross-polination with the LaunchPad-based Ubuntu L10n community, in > particular. They are a large community with a wide variety of > languages and they co-host a large number of Gnome originated > packages. Significant levels of (DL and LP) "dual citizenship" > already exist. > > I would like to make a couple of specific proposals about methods that > could be pursued in the outreach effort with regard to the LP-based > Ubuntu L10n community. > > 1) Provide a DL - LP cross mapping > > I suggest the creation of a "LaunchPad co-hosted Release Set" on the > Damned Lies server, similar in function to the "OLPC Release Set" that > was created by Claude Paroz and that I maintain. > > http://l10n.gnome.org/releases/olpc/ > > The purpose of this is to provide a quickly visible set of summary > statistics and quick links to packages that are hosted on both the > Damned Lies server (DL) and Ubuntu LaunchPad (LP). Ideally, this > release set should be maintained by someone involved in coordinating > Ubuntu translation efforts on LP (at an overall Ubuntu level, not > necessarily at a language-specific level). > > What would this accomplish and why is it a win-win? > > DL-based localizers (particularly those with an Ubuntu affinity) can > easily prioritize Ubuntu dependencies for completion in their DL work. > > LP-based localizers can easily identify opportunities to upstream > their work to DL and thereby reach a larger audience (e.g. other > Gnome-using distros) and leverage their efforts more widely. This > should particularly appeal to "language loyal" localizers, although > I'm sure the notion of sharing "Gnomey ngoodness" will also motivate > some. > > LP-based localizers can benefit from working on the DL master branches > of packages as a means of "pre-localizing" packages that, when > released as stable, will make make their way into LP and Ubuntu. Even > though the Ubuntu focus may be on an older stable release, by working > on a DL master branch, they are "getting ahead of the game", which > will allow them more time to focus on Ubuntu-specific strings that > change within an Ubuntu release cycle. > > I have attached a spreadsheet that is a first pass at mapping Gnome DL > project pages to Ubuntu (Quantal) LP project pages. I have not done a > drilldown to the specific release level. I think the focus should be > on master as the issues of version lag are pretty much a wash after a > few cycles as long as you focus on the master branch. The one > exception is where it looks like LP tracks a Gnome2 version separately > from a Gnome3 version, in those cases, I've left a blank cell > following the Gnome package name in the first column and added both > links in the LP column. > > I did this match by scanning: > > http://l10n.gnome.org/
Status of Khmer team?
What is the status of the Gnome Khmer L10n team? There have been completed PO files in vertimus pending since April. It would be good to have the strings landed. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Status of Khmer team?
That's great news. cjl On Tue, Sep 4, 2012 at 5:26 AM, Khoem Sokhem wrote: > Hello Chris, > > Our team is still active for Gnome localization to Khmer, yes of course for > a while we did not provide translations. > > We will start our translations soon from this month on. > > Thank for your alert! > > Cheer, > Sokhem > > > > On 04-Sep-12 4:06 PM, Chris Leonard wrote: >> >> What is the status of the Gnome Khmer L10n team? >> >> There have been completed PO files in vertimus pending since April. >> It would be good to have the strings landed. >> >> cjl >> ___ >> gnome-i18n mailing list >> gnome-i18n@gnome.org >> https://mail.gnome.org/mailman/listinfo/gnome-i18n >> > > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Bad stats for en_GB POs
Here are some examples of Damned Lies telling fibs about statistics. These en_GB PO files are completed, but the stats do not show it. http://l10n.gnome.org/vertimus/gegl/master/po/en_GB http://l10n.gnome.org/vertimus/xdg-user-dirs/master/po/en_GB http://l10n.gnome.org/vertimus/dconf/master/po/en_GB http://l10n.gnome.org/vertimus/json-glib/master/po/en_GB http://l10n.gnome.org/vertimus/libsoup/master/po/en_GB ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Bad stats for en_GB POs
On Wed, Sep 5, 2012 at 3:57 AM, Claude Paroz wrote: > Le mercredi 05 septembre 2012 à 03:26 -0400, Chris Leonard a écrit : >> Here are some examples of Damned Lies telling fibs about statistics. >> >> These en_GB PO files are completed, but the stats do not show it. >> >> http://l10n.gnome.org/vertimus/gegl/master/po/en_GB >> >> http://l10n.gnome.org/vertimus/xdg-user-dirs/master/po/en_GB >> >> http://l10n.gnome.org/vertimus/dconf/master/po/en_GB >> >> http://l10n.gnome.org/vertimus/json-glib/master/po/en_GB >> >> http://l10n.gnome.org/vertimus/libsoup/master/po/en_GB > > I don't see the en_GB.po files in the respective directories... > > Claude If you download them, by clicking on "PO file statistics: " link on the referenced pages they are "pre-completed" even though the stats say 0 complete. Should I just download them (already completed) and submit them via vertimus? Do you think that is an approach worth trying? I avoided trying that until giving you guys a chance to look into it. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
en_GB - Let's not miss these opportunities
Dear en_GB localizers, One of the great advantages of the relatively simple "translation" of en_us POT files into en_GB is that it gives you the opportunity to do much needed proofreading of the original en_US strings. I've encountered a few instances where typographical errors in the en_US original were simply corrected in the en_GB PO file, but no i18n bug had been filed against the package. vino (UPnP) https://bugzilla.gnome.org/show_bug.cgi?id=683387 There was another example in avahi "occured > occurred" When you encounter these typograhical errors while going through en_GB PO files (I'm not talking about the common orthographic variations, but genuine typos), please do not simply make the correction in the en_GB PO without filing the i18n bug. If you don't want to take the time to file the i18n bug, that is fine, but please leave the string untranslated and someone like me will get around to translating it later (after filing the i18n bug). Thank you for your attention to this matter. IMHO, the goal is to not only provide completed en_GB PO files, but also to improve the en_US original strings as opportunities present themselves. This will ultimately benefit all languages. Warmest Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Bad stats for en_GB POs
On Wed, Sep 5, 2012 at 4:34 AM, Claude Paroz wrote: > This pre-filling behaviour for en* locales seems to be a msginit feature > (which is the command run behind-the-scene by DL). > >> Should I just download them (already completed) and submit them via >> vertimus? Do you think that is an approach worth trying? I avoided >> trying that until giving you guys a chance to look into it. > > Yes, you can. However, if the file is absolutely identical to the > original strings, I don't see the point in submitting an en_GB.po file. > This is a waste of space/bandwidth/resource. As I mentioned in another message that crossed yours, I have a different point-of-view on "translating" en-GB. I personally see it as an excellent opportunity to proofread the en_US original and the en_GB completion is an easy indicator that the en_US strings have been proofread by an English speaker besides the developer. Maybe I hold this view because so many Sugar developers are native Spanish speakers, so I find lots of chances to offer improvements. Certainly enough Gnome developers are from European backgrounds with non-English mother tongues to make this a prudent step for Gnome as well. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: en_GB - Let's not miss these opportunities
On Wed, Sep 5, 2012 at 8:20 AM, Bruce Cowan wrote:
> Forwarded to the list because I pressed the wrong button.
>
> -- Forwarded message --
> From: Bruce Cowan
> Date: 5 September 2012 12:36
> Subject: Re: en_GB - Let's not miss these opportunities
> To: Chris Leonard
>
>
> On 5 September 2012 09:40, Chris Leonard wrote:
>> Dear en_GB localizers,
>>
>> One of the great advantages of the relatively simple "translation" of
>> en_us POT files into en_GB is that it gives you the opportunity to do
>> much needed proofreading of the original en_US strings.
>
> Yes, I was meaning to start earlier this cycle in order to do this,
> but I have been quite busy recently.
No worries. Busy is a standard condition for most FOSS contributors :-)
>> I've encountered a few instances where typographical errors in the
>> en_US original were simply corrected in the en_GB PO file, but no i18n
>> bug had been filed against the package.
>>
>> vino (UPnP)
>> https://bugzilla.gnome.org/show_bug.cgi?id=683387
>>
>> There was another example in avahi "occured > occurred"
>>
>> When you encounter these typograhical errors while going through en_GB
>> PO files (I'm not talking about the common orthographic variations,
>> but genuine typos), please do not simply make the correction in the
>> en_GB PO without filing the i18n bug. If you don't want to take the
>> time to file the i18n bug, that is fine, but please leave the string
>> untranslated and someone like me will get around to translating it
>> later (after filing the i18n bug).
>
> There's a tool in the gnome-i18n repository called en_GB.pl. You can
> use en_GB.pl --check to get a list of differences between the expected
> en_GB strings and the translations used. It misses a few ("ize" ->
> "ise"), but it's very useful for this sort of thing.
Bruce, yes, I do use the output of en_GB.pl as a reference for the
common word substitutions (trash > wastebasket) and the standard
transliterations. I still prefer an eyes-on approach to look for
possible i18n improvements.
I believe the OLPC Australia builds may use the en_GB packages (they
have 53,000 XOs) and I know that many XO laptops are used in schools
where English is the "language of instruction" and so I personally
feel that time spent on improving the en-US strings to a generally
high level of grammatical and orthographic correctness is worth the
effort.
cjl
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: en_GB - Let's not miss these opportunities
On Wed, Sep 5, 2012 at 6:56 PM, Sridhar Dhanapalan wrote: > On 6 September 2012 02:54, Chris Leonard wrote: >> >> I believe the OLPC Australia builds may use the en_GB packages (they >> have 53,000 XOs) > > That is correct. Our default language is en_GB. > > Sridhar Now all we need is an e-speak voice that sounds more like Paul Hogan and less like Stephen Hawking doing an impression of Margaret Thatcher. :-) If anyone has an interest in expanding the repertoire of e-speak voices I'd be interesting in discussing it with you.. I know e-speak is not a GNOME project, but Orca is just a bit too heavyweight for the XO's light-duty hardware specs. http://espeak.sourceforge.net/languages.html Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Fwd: New team for [Central Nahuatl] ([ISO 639-3 nhn])
On Sat, Sep 8, 2012 at 1:49 PM, Gil Forcada wrote: > Congratulations! The first stone to this never-ending journey has been > started ;) > > Please add yourself to the newly created language on Damned-Lies: > http://l10n.gnome.org/languages/nhn/ > > Now, apart from translation GNOME 3.6 to Central Nahuatl[1] you should > try to spend some time creating your locale[2]. Without that you will > not be able to select your language and see your translations! Locale creat4ed and filed http://sourceware.org/bugzilla/show_bug.cgi?id=14501 > Keep asking anything that blocks you! We are all here to help everyone > to be able to use their loved desktop in their loved language! The current block on the locale seems to be getting the attention of the glibc maintainers. It would be very desirable is someone from The GTP Coordination Team could be deputized by the ghlibc maintainers to move new locales forward quickly. > Happy translating!! > > [1] http://l10n.gnome.org/languages/nhn/gnome-3-6/ui/ > [2] http://translate.sourceforge.net/wiki/guide/locales/glibc > > El ds 08 de 09 de 2012 a les 11:56 -0500, en/na jorge becerril va > escriure: >> Here are the files you nhn.orth and the gnome-icon-theme.master.pot >> files. >> >> >> 2012/9/4 Chris Leonard >> Jorge, how are you doing on the other steps outlined in >> >> https://live.gnome.org/TranslationProject/NewLanguage >> >> If the glibc locale is filed and you have done all of the >> other steps >> listed on that link, I do not think they will make you wait >> for the >> glibc locale t obe committed. >> >> The best thing to do now is to move forward on the other >> steps. >> >> >> 1) Create an nhn.orth file as described, >> >> 2) Translate a PO file offline for submission. >> >> cjl >> >> -- Forwarded message -- >> From: Gil Forcada >> Date: Wed, Aug 8, 2012 at 2:38 AM >> Subject: Re: New team for [Central Nahuatl] ([ISO 639-3 nhn]) >> To: gnome-i18n@gnome.org >> >> >> El dt 07 de 08 de 2012 a les 04:52 -0500, en/na jorge becerril >> va >> escriure: >> > NAME: Jorge Becerril Cejudo >> > e-mail: jrbecster@gmail,com >> > bugzilla account: jrbecs...@gmail.com >> > Language name en_US.UTF-8: Central Nahuatl >> > Language name es_MX.UTF-8: Central Nahuatl >> > ISO: 639-3 nhn >> > Language name: Central Nahuatl >> >> >> Hi Jorge, >> >> Welcome to the GNOME Translation Project! >> >> Did you take a look at >> https://live.gnome.org/TranslationProject/NewLanguage ? >> >> Could you register on http://l10n.gnome.org and do a small >> translation >> so that we can set up your team? >> >> For example this two strings translation: >> >> http://l10n.gnome.org/POT/gnome-icon-theme.master/gnome-icon-theme.master.pot >> >> Once translated, send it back to this mailing list or >> privately and we >> will setup all details on http://l10n.gnome.org. >> >> Happy translating! > > -- > Gil Forcada > > [ca] guifi.net - una xarxa lliure que no para de créixer > [en] guifi.net - a non-stopping free network > bloc: http://gil.badall.net > planet: http://planet.guifi.net > > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: BoF item 12/14: improvements to gtranslator
On Thu, Aug 2, 2012 at 4:05 PM, Gil Forcada wrote: > Hi all, > > As I said in previous mails, let this mail be a kickstart for giving > feedback about the items that are defined on > https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012 > > In this mail please give feedback about the improvements on gtranslator > item. > > Cheers, > -- > Gil Forcada Quoting from: https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012#Improvements_to_gtranslator Improvements to gtranslator Background: A brainstorming session was run over which improvements will be nice to have on gtranslator. Right now gtranslator is short on developers, so having a bullet point in this list does not mean it will be implemented in short or at all if the situation does not change. Bullet points: open to review patches I guess my question would be "Why?". Have you taken a good look at Virtaal and the Translate Toolkit? I personally think they are the best thing since sliced bread when it comes to off-line L10n work. http://translate.sourceforge.net/wiki/virtaal/index http://translate.sourceforge.net/wiki/toolkit/index Instead of putting developer effort into gtranslate, put that effort into converting Claude Paroz's Locale Helper web-app into a submission workflow for glibc locales along the lines of CLDR's Survey Tool. Or maybe work on enhancing the Translate Toolkit or Virtaal (if there is something that you think they need). Howwever; there is no need to fall prey to the "not-invented-here" syndrome. Perfectly good solutions exist, under suitable licensing and with established developer communities that it would be better to join rather than re-code what they have already done. Sure, the Translate Toolkit and Virtaal are not perfect. No offense intended to Friedel Wolff or the other superb translate.org devs but as one example, I personally think POlogy does a better job of producing differential PO files from two related input PO files (a task I repeat occasionally), so the answer that makes sense to me is to port the good things from other projects into TT and Virtaal to make a really, really good product even better. Reinventing the wheel just seems like a waste of time. Of course, I really like TT and Virtaal, maybe others have similarly strong feelings about different tools like gtranslator or POedit. It is never a waste of time defining important features and examining the options to see what is best overall, but IMHO, I've settled on Virtaal as the best-of-breed and would rather see work go into it than playing catch up on gtranslator. Choice is good, but I've made mine and I would encourage others to try it before committing a lot of effort to something else. I have no intent to belittle the efforts of others, as I said, for certain tasks I find that other tools work more intuitively or efficiently, I just find that for me Virtaal has an overall advantage as an off-line PO editor and that the TT allows me to do most of the other manipulations of PO files I want to do. YMMV. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: BoF item 12/14: improvements to gtranslator
On Mon, Sep 10, 2012 at 4:36 AM, Daniel Mustieles García wrote: > Sorry, but I disagree with you. Absolutely no need to apologize. I asked the question 'Why" and you've given me an answer, thank you. I respect your opinion even if ti differs from mine, we share far too much in our common interest in bringing Gnome to as many languages as possible to not be able to have a perfectly civil conversation (as we are) about the optimal tactics for achieving common goals. I sincerely have no wish to start a flame war or a "My favorite tool is better than yours" back and forth.. I do apologize if my enthusiasm for Virtaal came across as speaking ill of other tools. Choice is good. > > Gtranslator is a very powerful, easy and intuitive translation application. > It's interface is simple, because it hasn't floating elements in the window, > and it has separated boxes for original string, translated string and > messages table. > > Also, having several tools for the same purpose is not a bad thing; if we > just had one tool for translating, and its maintainer decided to leave the > project... what would we do? Use Lokalize? ;-) > > Gtranslator has a really good plugins system, which allows to expand it > easily. Instead of killing it, we should fight to create a development group > to fix and improve it. Also, as I said at GUADEC, I think GT should be part > of the GNOME desktop applications (since Anjuta is the official IDE, GT > should be the official translation app). Maybe it would help to find someone > to maintain it. I would agree with you that promoting gtranslator from "Extra GNOME applications" to a more prominent Release Set might be a good tactic for raising it's profile within the GNOME project. > GT is done, it's working, and a lot of people uses it. Why don't we try to > fix it? It isn't completely broken; just 2 or 3 important bugs, but it works > perfectly... are you sure you want to drop it? I don't agree and I'll keep > myself trying to improve it, and looking for a maintainer. If we can't > create or fix our own tools, what are we doing? I'm sure you'll agree with > me it's stupid, por example, to develope GNOME Shell under .NET Framework > isn't it? Is the same case with GNOME translations and Lokalize. Many people > uses Lokalize to translate GNOME... WTF! GNOME is a big project, with a > great Marketing and a really great i18n teams... aren't we able to find a > developer and/or a maintainer to fix and improve our translation tool? I > don't think so. > > Instead of deprecating a working application, help us to fix and improve it. > Please, don't let it die. I concede that it would be potentially embarrassing and very possibly send the wrong message about GNOME's commitment to L10n, but in the end of the day, developers and users will "vote with their fingers and eyeballs". I suspect that I obscured my main message with my expression enthusiasm for Virtaal. The GNOME project (like any) has limited developer resources, it is my opinion that improving the submission process for glibc locales would have a higher impact on overall GNOME i18n than improving gtranslator, given the plethora of options available for PO file editing. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Release set inclusion criteria?
Dear Release Set maintainers, What exactly qualifies a package for inclusion in the Release Set "External Dependencies (GNOME)"? Given that Epiphany Web Browser http://l10n.gnome.org/module/epiphany/ has a dependency on WebKitGTK+ (and it's L10n), does WebKitGTK+ qualify for that or some other more prominent Release Set? http://l10n.gnome.org/module/webkit/ Note these tickets (from Epiphany dev asking for WebKitGTK+ L10n): https://bugzilla.gnome.org/buglist.cgi?quicksearch=610094%2C+610095%2C+610102%2C+610103%2C+610106%2C+610109%2C+610110%2C+610111%2C+610112%2C+610113%2C+610115%2C+610118%2C+610120%2C+610125%2C+610128%2C+610129%2C+610135%2C+610138%2C+610139%2C+610142%2C+610144%2C+610145%2C+610146%2C+610147%2C+610149%2C+610150%2C+610151%2C+610153%2C+610155%2C+610158%2C+610159%2C+610160%2C+610161%2C+610162%2C+610163%2C+610164%2C+610165 The importance of this is that WebKitGTK+ is not presently a member of any Release Set (other than OLPC) and it is not getting the L10n it deserves. Yes, it is absolutely true that WebKitGTK+ has other issues with it's i18n at present, but making it more visible can only help that i18n issue get the attention it requires. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Release set inclusion criteria?
On Tue, Sep 11, 2012 at 3:26 AM, Claude Paroz wrote: >> The importance of this is that WebKitGTK+ is not presently a member of >> any Release Set (other than OLPC) and it is not getting the L10n it >> deserves. >> >> Yes, it is absolutely true that WebKitGTK+ has other issues with it's >> i18n at present, but making it more visible can only help that i18n >> issue get the attention it requires. > > There are several other external packages that contain visible strings > in GNOME (notably those hosted on the Translation Project). We (I?) > choose at some point to limit ourselves to GNOME git + some freedesktop > translation stats. It's somewhat arbitrary and we can decide to change > it or add more exceptions. But generally-speaking I find it rather > frustrating to have statistics on packages you may have to wait several > months before anyone react upstream :-/ > > As for WebKitGTK+, it's not an option to make it more visible until DL > can generate a proper POT file. The last time it succeeded was on > 2010-12-27! Yes, I am painfully aware of the failure of WebKitGTK+ to provide an adequate fix for their i18n issue. Part of my reasoning for wanting it to make it more visible (other than the fact that all GNOME-based web-browsing depends on it) is to draw greater attention to the i18n issue. It is with sorrow that I understand localizers staying away from WebKitGTK+ work, but I feel that the fact that WebKitGTK+ is somewhat "hidden" by not appearing in any DL release set is only aiding and abetting the failure of the WebKitGTK+ i18n when we should be shining a harsh spotlight on this long-standing issue. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: BoF item 12/14: improvements to gtranslator
On Tue, Sep 11, 2012 at 4:10 AM, Daniel Mustieles García wrote: > Working together, I'm sure we will be able to grow up GT and translation > teams. I don't know how difficult is the issue about locales in glib, but if > I cand help with it, please let me know. I have tried a few different off-line PO editing tools I will spend some time with Gtranslator to see if I can propose some cogent feature enhancements to capture what I think are the best features of those I am more familiar with. I'll also take a good look at it's size footprint on disk. Virtaal is a 15 MB install on the Gnome-boot side of an XO laptop, finding something with a lighter footprint might be helpful in achieving one of my dreams/goals for Sugar, which is the ability to "bootstrap" localization from Sugar without an internet connection. Size is a major issue on the many XO-1 laptops out there that have only 1GB total space for everything. Sadly, what I can't do is code those features myself, I am much more of a string and community wrangler than a coder. Nor can I offer advice on where to find developers for those tasks. That is a real challenge, there are always more good ideas than there are people to code them. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Errors in documentation tags
On Thu, Sep 13, 2012 at 8:09 AM, Daniel Mustieles García wrote: > Yes, I've considered it several times, but the main script I've developed > (GTTK) has several bugs, and i'd like to fix them before sharing it with a > big README file ;-) > > I hope I'll have some time these days to work on it and, when I fix it, sure > I'll share it on github. > > BTW, as soon as I have time to create a repo and upload the scripts, I'll > share them in this mail list. > > Many thanks for your interest! Dear Daniel, Thank you for this effort. Creation of workflows like this for global (or even individual) quality control is a wonderful contribution. I would not be too concerned about sharing them prior to final polishing as I think you have a very welcoming audience of beta testers on this list. I would encourage you to look at the Translate Toolkit for inspiration (or bits of code to borrow) as there are lots of widgets that perform similar work in a PO-file aware manner. The widgets there are readily wrapped in a little bash script for bulk operations. http://translate.sourceforge.net/wiki/toolkit/index For instance, I think a similar check is performed by the pofilter tool under the xmltags flag. translate.sourceforge.net/wiki/toolkit/pofilter_tests Just as a potential target for another such global analysis workflow, in my experience with Sugar Labs, I find that printf errors and mismatched terminal newlines are the most common causes of PO files causing build failures. One of the interesting things about xmltags, printf errors and terminal newlines mismatches is that very often, one does not need to be able to read the language in question to be able to provide a suitable correction. Simple understanding of the syntax of the original string is often sufficient to identify the error and correct it. I would also like to point out that one of the current Gnome Goals https://live.gnome.org/GnomeGoals/RemoveMarkupInMessages is, in fact, to find and remove markup from UI messages. I imagine your tool could be adapted to search for the presence of such tags in UI strings. I have filed a few i18n enhancement tickets on packages pointing out the Gnome Goal above where there was a lot of markup and referencing specific lines (from the PO location comment). At some point I may take a look at going back over them and trying to provide patches where the original developers have not taken action on their own. Warmest Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Automated translation by word substitution
On Thu, Sep 13, 2012 at 9:15 AM, Rūdolfs Mazurs wrote: > Hi all, > > does any team uses automated substitution method for translating > software? I imagine en_GB team could get their software translated just > by substituting, say, color with colour. If so, is there a > software/script/plugin, that does that? en_GB has this PERL script as a first pass at transliterations and simple word substitutions. I personally feel that a human-eyes check is necessary after a first pass, but as I've mentioned on the list I also see en_GB work as an opportunity to improve the original en_US strings where they need work. http://git.gnome.org/browse/gnome-i18n/tree/en_GB/en_GB.pl cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Repetitive strings in many modules
On Sat, Sep 15, 2012 at 9:04 PM, Ask Hjorth Larsen wrote: > Hi translators and i18n people > > I notice that the string "Quit" seems to have appeared in quite a few > modules. In total, the msgids "Quit" or "_Quit" (i.e. matching > "^(_?)Quit$") are found 31 times, in these modules: > > > Why not use a stock label for this kind of stuff? There are also many > instances of About and _About which I don't recall from previous > releases. > > Regards > Ask Yes, Strings like this are a good reason to use an off-line PO editor with a good translation memory feature or an on-line tool like Pootle that has a glosssary/terminology project. It would be a thought to crunch a glossary.po terminology project for GNOME using poternimology from theTranslate Toolkit. At the very least, people could download it to their local TM to help maintain consistency in translations of certain common terms. The main problem (as I see it) is that GNOME is not a monolithic project. It is a very large collection of independent projects that strive to be interoperable. I don't know that carving strings like this out into a separate software package called when needed would ever really work for the developers. They would simply introduce the strings they feel they need for their UI and not reference an external source for them. It is far too great a "social engineering" problem. As a simply technical matter it is much easier to address this issue by working with a local TM. I am entirely in favor of filing i18n bugs to promote common-sense string conventions when possible (Why have "Zoom in" and Zoom In" and 'ZOOM IN" if you can possibly agree on one string), but even then it is a matter of getting devs to agree on one convention. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Repetitive strings in many modules
On Sun, Sep 16, 2012 at 12:31 PM, Gil Forcada wrote: >> I am entirely in favor of filing i18n bugs to promote common-sense >> string conventions when possible (Why have "Zoom in" and Zoom In" and >> 'ZOOM IN" if you can possibly agree on one string), but even then it >> is a matter of getting devs to agree on one convention. > > That's another issue that I would really like to see happening, someone > stepping in and adding some cohesion/consistency to original strings. a > GWOP/GHOPC would be really useful here. Anyone stepping in to do > administrate it? :) Can you define the acronyms GWOP/GHOPC? I am generally interested in cross-project consistency. First, there is the purpose of providing a user experience that enhances package-to-package "transferable skills" learning (as in "Gee, I bet I know what 'Save' does, but I have no idea what this 'Preserve' / 'Retain' / 'Keep' item in the pull-down menu means). Consistency of original string (and its translation) in common pull-down menu items (in particular) is a desirable feature, not always attainable, but worth working towards. It is also a lot easier to look for consistency in translations if there is consistency in the original en_US strings. Subtle, but essentially meaningless, variations in the original (e.g. capitalization, punctuation on short strings, etc.) just makes those larger-scale translation consistency analyses more complex. Secondly, there are the hopefully obvious advantages to localizers in making on-line translation memory efforts more useful (e.g. Amagama, open-trans.eu, etc.), again it helps if the en_US strings have a sensible consistency. There will not always be a one-to-one match from an en_US string to a term in a given language, context is obviously critical, but that is why we have human translations, to include the critical element of judgment. The language universe of computer program UIs is somewhat more limited than the full complexity of human language. There are only so many ways to describe the functions performed by a word processor or a chess game. Voluntarily adopted consistency in terms may seem to be an overly ambitious goal, but I think even incremental progress is worth achieving. We should not even attempt to achieve the level of mandated consistency seen in fields like medical encoding (HL7, MEDRA, ICD-10, etc.), but as a professional user of those sorts of controlled vocabularies and ontologies, there are elements those approaches to knowledge representation that are worth emulating on a smaller scale. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: intltool-update does not display warnings if there is no error
On Sun, Sep 16, 2012 at 1:59 PM, Bruno Coudoin wrote: > > Sorry for not being clear. I wanted to share my pain with you to see if > this also impacts you. > > I just created a bug here (I hope it is the right place): > https://bugs.launchpad.net/intltool/+bug/1051654 Bruno, You have my sympathy on your intltool problem. intltool is apparently causing a number of issues for i18n of downstream projects WebKitGTK+ intltool problem https://bugs.launchpad.net/intltool/+bug/823217 GIMP intltool problem https://bugs.launchpad.net/intltool/+bug/986897 I was not entirely comforted nor satisfied by the intltool dev's reply on the WebKitGTK+ ticket, which was more or less, if it bothers you, then provide a patch. I hope you get a more satisfactory response. I wish I had something more encouraging to offer than that gloomy assessment. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Repetitive strings in many modules
On Sun, Sep 16, 2012 at 3:10 PM, Ask Hjorth Larsen wrote: > Also, not too many releases ago something similar happened where > several messages appeared in many modules. Like "Unrecognized desktop > file version" (I still remember that one). It's a bit strange, that's > why I ask. > > Regards Ask I can't say for sure, but it is always possible that such a flurry of common UI strings simultaneously appearing in different projects could perhaps come about because of coordinated efforts via the Gnome Goals https://live.gnome.org/GnomeGoals/ For example this one: https://live.gnome.org/GnomeGoals/RemoveMarkupInMessages will hopefully result in a large number of PO files being modified to remove the markup (xmltags) that often appear in strings. However, that is purely speculation on my part about the appearance of "About" strings in this case. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Repetitive strings in many modules
On Sat, Sep 22, 2012 at 6:02 AM, Kenneth Nielsen wrote: > Den 17-09-2012 10:22, Alexandre Franke skrev: >> >> On Sun, Sep 16, 2012 at 9:46 PM, Piotr Drąg wrote: >>> >>> This is actually an effect of >>> https://live.gnome.org/GnomeGoals/PortToGMenu goal. The new menus >>> don't use stock GTK+ entries for some reason. >> >> >> Shouldn't we open a bug for that? Or maybe that's already been filed? > > > I think the main point of the original post got lost a bit along the way. > > We already have a collection of stock menu (including strings) and menubar > items in GTK+ to prevent introducing (and translating) these ~100[1] strings > again and again, so the question is, why is it not being used. I can see a > few different options here. > > 1) Developers don't like using them, because it puts a part of their program > out of their control or something like that (unlikely I would say as GNOME > is already built up around a set of shared libs). > SOLUTION: Not much we can do about that unless the use of them made a > priority by including them in a GNOME style guide or made a gnome goal or > something like that. > > 2) Developers aren't aware of them or forget about them in the heat of > writing brilliant code. > SOLUTION: In that case we (translators) should then be making bugs for each > module individually. > > 3) Developers forgot about them in the transition to GMenu. Unlikely I would > say, that if they already used them that they wouldn't use them again if it > was possible. > SOLUTION: In any case the solution is the same as above > > 3) A bug in GMenu (or elsewhere) that prevents the use of them. > SOLUTION: So to answer Piotr, yes, I think we should definitely file a bug > about it. Then we just need to make sure that GMenu is the right place to > file it. > > 4) Some technically unsolvable issue with GMenu that prevents using them. > "SOLUTION": Moping :( > > So if there anyone here that can shed some light on which one of them is the > right explanation? > > Regards Kenneth > > [1] http://developer.gnome.org/gtk/2.24/gtk-Stock-Items.html > I am very interested in the answers to Kenneth's questions about why they might not be used. Working towards "string" consistency and easing the L10n burden are areas of interest to me. Depending on the answers to the scenarios posed (i.e. not 1 or 4), I could easily imagine myself undertaking a search-and-file-bug project across Damned Lies. In going through the en_GB "translation" I have been filing a reasonable number of "fix typo" bugs and "please remove markup" bugs (markup being related to another Gnome Goal) Finding occurrences of the stock item strings throughout Damned Lies hosted PO files is no particular challenge. Developing a little text template for quickly composing this type of bug is trivial. Whether filing "please use stock strings" bugs (without a corresponding patch) will achieve action, I can't say, but it is an opportunity to educate developers and address cases 2 and 3 above. I haven't been filing patches with my "fix typo" bugs because most devs can (and hopefully will) do this trivially in their local clones (I provide the PO location line and explicit recommendation for the change), Besides we are in string freeze for a while longer anyway. I am likely to go back over those at my leisure and attach patches to prompt further action if it is not taken by the devs in a "reasonable" period of time. If scenarios 2 or 3 are considered the likeliest causes, I might take a stab at this. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Malayalam (ml) not mentioned among supported languages in Gnome 3.6
On Thu, Sep 27, 2012 at 11:59 AM, Andre Klapper wrote: > On Thu, 2012-09-27 at 20:58 +0530, Ani Peter wrote: >> Malayalam (ml) has 82% status for UI translations in Gnome 3.6 (84% for >> UI translations reduced) [1]. But I cannot find my language listed in [2]. >> Please let me know the reason for the same or guide me if I am missing >> anything. > > Hi, > > it's my mistake, and I'm very sorry for that. I accidentially removed it > in commit 2b92a093d3109d1f1453394f82638c774ad1e79c . > > If we re-added it it would create a new string to translate for all > other teams so I'm not sure what to do. > Maybe I can take a look at older release notes and reuse the > translations for "Malayalam" from there so it would not create > additional work for the teams. Andre, Just wanted to share two of my favorite tricks for finding localized language names. 1) Look it up in the ISO639 or ISO-639-3 PO files for the relevant language. http://anonscm.debian.org/gitweb/?p=iso-codes/iso-codes.git;a=tree 2) Look up the Language article in English Wikipedia, check out the left hand bar for an interwiki link to the same article in another language's Wikipedia. Not surprisingly, there are a high percentage of languages with wiki articles on their own language (in their own language), so this is not quite as random as it may seem. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Best way to format a name string in Folks
On Thu, Sep 27, 2012 at 11:10 AM, Philip Withnall wrote: > On Sun, 2012-08-05 at 00:55 -0400, Chris Leonard wrote: >> My own point of view on this is that I find it frustrating when >> developers to ask a localizer to do a job that the glibc locale should >> be capable of addressing all on it's own. Translating Day and Month >> names should be banned in PO files :-) >> >> There is in fact an entire section in glibc locales called LC_NAME in >> the glibc locale that has a field for Name format (name_fmt) as >> described below. My argument is that develoeprs should leverage the >> information content of the glibc locale to the greatest extent >> possible, that is after all the primary purpose of having glibc locale >> files. > > That looks great, but how do I use it from C (or Vala)? The best I can > find so far is retrieving the translated name_fmt using > nl_langinfo (_NL_NAME_NAME_FMT) > and then implementing the substitution of the field descriptors myself, > which does not sound like fun at all. Something like strftime() (but for > names) would be great. I just can't find it. > > Thanks, > Philip Philip, I may have to apologize for speaking before investigating the specifics of LC_NAME. After looking at these links: http://www.gnu.org/software/libc/manual/html_node/Locale-Information.html#Locale-Information http://www.gnu.org/software/libc/manual/html_node/The-Elegant-and-Fast-Way.html#The-Elegant-and-Fast-Way I would have to admit that the information in the glibc locale is not as accessible as I thought it was. To achieve my idealized notion of locale data accessibility, it is possible that the X/Open upstream would need to be modified or an LC_NAME equivalent of strftime() created as you suggest. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Malayalam (ml) not mentioned among supported languages in Gnome 3.6
On Thu, Sep 27, 2012 at 1:50 PM, Chris Leonard wrote: > On Thu, Sep 27, 2012 at 11:59 AM, Andre Klapper wrote: >> On Thu, 2012-09-27 at 20:58 +0530, Ani Peter wrote: >>> Malayalam (ml) has 82% status for UI translations in Gnome 3.6 (84% for >>> UI translations reduced) [1]. But I cannot find my language listed in [2]. >>> Please let me know the reason for the same or guide me if I am missing >>> anything. >> >> Hi, >> >> it's my mistake, and I'm very sorry for that. I accidentially removed it >> in commit 2b92a093d3109d1f1453394f82638c774ad1e79c . >> >> If we re-added it it would create a new string to translate for all >> other teams so I'm not sure what to do. >> Maybe I can take a look at older release notes and reuse the >> translations for "Malayalam" from there so it would not create >> additional work for the teams. FWIW, There is another reasonable source of localized in the CLDR locales. Not as easy to browse as there is no convenient interface, you have to download th ewhole package. Attached is a grep of lang-ml name translations in the CLDR locales. cjl main/af.xml:Malabaars main/am.xml:ማላያላምኛ main/ar.xml:الماليالام main/be.xml:малаяламская main/bg.xml:малаялам main/br.xml:malayalam main/brx.xml: मलयालम main/bs.xml:malajalam main/ca.xml:malaialam main/cs.xml:malabarština main/da.xml:malayalam main/de.xml:Malayalam main/ee.xml:malayagbe main/el.xml:Μαλαγιαλάμ main/en.xml:Malayalam main/eo.xml:malajalama main/es.xml:malayalam main/et.xml:malajalami main/eu.xml:malayalamera main/fa.xml:مالایالامی main/fi.xml:malajalam main/fr.xml:malayalam main/ga.xml:Mailéalaimis main/gl.xml:malabar main/gsw.xml: Malayalam main/gu.xml:મલયાલમ main/he.xml:מלאיאלם main/hi.xml:मलयालम main/hr.xml:malajalamski main/hu.xml:malajálam main/id.xml:Malayalam main/is.xml:malajalam main/it.xml:malayalam main/ja.xml:マラヤーラム語 main/km.xml:ភាសាម៉ាឡាឡាយ៉ាន main/kn.xml:ಮಲೆಯಾಳಂ main/kok.xml: मळियाळम main/ko.xml:말라얄람어 main/lt.xml:malajalių main/lv.xml:malajalu main/mk.xml:малајалам main/ml.xml:മലയാളം main/mr.xml:मल्याळम main/mt.xml:Malajalam main/my.xml:မလေးရာလမ် main/nb.xml:malayalam main/nl.xml:Malayalam main/nn.xml:malayalam main/om.xml:Malayaalamiffaa main/or.xml:ମାଲାୟଲମ୍ main/pl.xml:malajalam main/pt.xml:malaiala main/ro.xml:malayalam main/ru.xml:малаялам main/rw.xml:Ikimalayalami main/sk.xml:malajálamčina main/sl.xml:malajalamščina main/sr_Latn.xml: Malajalam main/sr.xml:Малајалам main/sv.xml:malayalam main/sw.xml:Kimalayalam main/ta.xml:மலையாளம் main/te.xml:మలయాళం main/th.xml:มาลายาลัม main/ti.xml:ማላያላምኛ main/to.xml:lea fakaʻinitia malāialemi main/tr.xml:Malayalam main/uk.xml:малайялам main/vi.xml:Tiếng Malayalam main/zh_Hant.xml: 馬來亞拉姆文 main/zh.xml:马来亚拉姆文 main/zu.xml:isi-Malayalam ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Malayalam (ml) not mentioned among supported languages in Gnome 3.6
On Sat, Sep 29, 2012 at 8:22 PM, Andre Klapper wrote: > On Fri, 2012-09-28 at 08:30 +0530, Ani Peter wrote: >> I would therefore kindly request you to expedite inclusion of >> Malayalam (ml) to the supported language list. > > Fixed now. Again sorry, and big thanks to Chris for providing a list of > translations! I am very glad to have been helpful and even more glad that the hard work of the Malayalam team can take it's rightful place on the supported languages list. Warmest Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Question about WebKitGTK+ in Damned Lies
Dear DL admins, If the WebKitGTK+ devs can manually generate the POT file, is there a way to get this up in Damned Lies? http://l10n.gnome.org/module/webkit cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Question about committer versus coordinator
So what happens when a team has a coordinator, but not a committer (like Khmer)? The Coordinator has marked a number of PO files for commit in vertimus, http://l10n.gnome.org/languages/km/all/ui/ If a team does not have a committer, will someone else commit those on the Coordinator's request or does each team require a committer? Thanks for helping me learn more about how things work in the vertimus workfow. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Question about committer versus coordinator
On Wed, Oct 3, 2012 at 6:19 AM, Bruno Brouard wrote: > Le 03/10/2012 10:44, Chris Leonard a écrit : > >> So what happens when a team has a coordinator, but not a committer (like >> Khmer)? >> >> The Coordinator has marked a number of PO files for commit in vertimus, >> >> http://l10n.gnome.org/languages/km/all/ui/ >> >> If a team does not have a committer, will someone else commit those on >> the Coordinator's request or does each team require a committer? > > Just ask on this list for help for the commit and someone will do the job. > But please, join links to the modules marked as "ready for commit" > > Bruno Bruno, Thanks. The Coordinator has applied for a commit account, in the meantime, if someone could commit the following which are flagged as ready to commit that would be great. http://l10n.gnome.org/vertimus/PolicyKit-gnome/master/po/km http://l10n.gnome.org/vertimus/empathy/master/po/km http://l10n.gnome.org/vertimus/eog/master/po/km http://l10n.gnome.org/vertimus/evince/master/po/km http://l10n.gnome.org/vertimus/gedit/master/po/km http://l10n.gnome.org/vertimus/gimp/master/po-tags/km http://l10n.gnome.org/vertimus/gnome-bluetooth/master/po/km http://l10n.gnome.org/vertimus/gnome-control-center/master/po/km http://l10n.gnome.org/vertimus/gnome-disk-utility/master/po/km http://l10n.gnome.org/vertimus/gnome-games/master/po/km http://l10n.gnome.org/vertimus/gnome-media/master/po/km http://l10n.gnome.org/vertimus/gnome-nettool/master/po/km http://l10n.gnome.org/vertimus/gnome-power-manager/master/po/km http://l10n.gnome.org/vertimus/gnome-screensaver/master/po/km http://l10n.gnome.org/vertimus/gnome-session/master/po/km http://l10n.gnome.org/vertimus/gnome-settings-daemon/master/po/km http://l10n.gnome.org/vertimus/gnome-system-monitor/master/po/km http://l10n.gnome.org/vertimus/gnome-terminal/master/po/km http://l10n.gnome.org/vertimus/gnome-user-share/master/po/km http://l10n.gnome.org/vertimus/gnome-vfs/master/po/km http://l10n.gnome.org/vertimus/gtk+/master/po-properties/km http://l10n.gnome.org/vertimus/gtk+/master/po/km http://l10n.gnome.org/vertimus/libbonobo/master/po/km http://l10n.gnome.org/vertimus/libbonoboui/master/po/km http://l10n.gnome.org/vertimus/libgnomekbd/master/po/km http://l10n.gnome.org/vertimus/libgnomeui/master/po/km http://l10n.gnome.org/vertimus/libwnck/master/po/km http://l10n.gnome.org/vertimus/nautilus-sendto/master/po/km http://l10n.gnome.org/vertimus/network-manager-applet/master/po/km http://l10n.gnome.org/vertimus/packagekit/master/po/km http://l10n.gnome.org/vertimus/totem/master/po/km http://l10n.gnome.org/vertimus/vino/master/po/km http://l10n.gnome.org/vertimus/xdg-user-dirs/master/po/km http://l10n.gnome.org/vertimus/yelp/master/po/km http://l10n.gnome.org/vertimus/yelp-xsl/master/po/km ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Question about committer versus coordinator
On Wed, Oct 3, 2012 at 7:10 AM, Gil Forcada wrote: > El dc 03 de 10 de 2012 a les 12:19 +0200, en/na Bruno Brouard va > escriure: >> Le 03/10/2012 10:44, Chris Leonard a écrit : >> > So what happens when a team has a coordinator, but not a committer (like >> > Khmer)? >> > >> > The Coordinator has marked a number of PO files for commit in vertimus, >> > >> > http://l10n.gnome.org/languages/km/all/ui/ >> > >> > If a team does not have a committer, will someone else commit those on >> > the Coordinator's request or does each team require a committer? >> Just ask on this list for help for the commit and someone will do the job. >> But please, join links to the modules marked as "ready for commit" > > +1 That's what I think about it: > - Coordinator is the one that approves translations to be pushed to git > - Only coordinator and any committer are the ones that should be able to > push to git > - In case of no coordinator git access and no committer, the > coordinator, and only him/herself should be the one sending batch mails > with translations ready to push I don't disagree, however in this case, I was giving notification of PO files that the coordinator had manually flagged for commit. > I put emphasis on this last one because if a random translator for a > random language send translations to push, I don't know the status of > that translation, if is good enough, if has bad wordings, etc etc. > That's why we have coordinators. > > And that's the main reason that I think of a coordinator not as a > "emeritus" status but as someone that is there 90% of the time. If you > are not able to coordinate your translation community and be sure that > translations, when ready, are pushed to git, that coordinator should > start looking for a replacement. As a general principle. I agree. The sad reality is tha there are any number of low coverage languages that simply do not have the sort of internet presence to sustain that standard, but they are no less worthy of following a slower course to increasing coverage. I many cases there may be only one or two individuals working on their language across a wide swath of FOSS projects and they may not have the bandwidth to dedicate constant attention only to a single project, no matter how important it may be. In such circumstances I think allowances must be made for long latency and some administrative assistance form the 18n leadership. Those opinions have largely been formed over the past several years in the process of nurturing and mentoring under-represented languages on the Sugar Labs Pootle instance. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Obsolete Belarusian translations
On Mon, Oct 8, 2012 at 4:32 PM, Piotr Drąg wrote: > Thanks for the explanation! That made some things clear. It's sad to > see translations removed, even if they are old and problematic. I > understand that your team is understaffed (or even this is an > understatement? :D), but maybe you could reach out to translators of > other FLOSS projects? There seems to be a decent sized team working on LaunchPad lang-be https://translations.launchpad.net/+languages/be https://launchpad.net/~lp-l10n-be https://launchpad.net/~ubuntu-l10n-by They also host gnome packages that could possibly be upstreamed (after review). Might be worth looking into. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modules split proposal (yeah, another one, sorry)
Gil, I would coment that WebKitGTK+ is not on your list, but is required for a completely localized Epiphany experience. I'm still agitating for some improvement (hackish or otherwise) in the WebKitGTK+ failure to produce a valid POT file (for the past two years), but that is a separate matter. cjl On Fri, Oct 12, 2012 at 6:02 PM, Gil Forcada wrote: > Hi all, > > See attached (right now I do not have Internet to put that on > live.gnome.org at [1]) a new proposal for the modules splitting (related > to bug [2]). > > The current proposal is actually really good, but I think it can be even > better (hence my proposal). What I do really don't like is to tie > together the libraries with the apps. > > I completely agree that the strings on the libraries are actually seen, > and some of them are quite visible, but if the target still remains to > translate everything, let's make it harder at the end rather than at the > beginning. That way, when you are more than half-way of the translations > and you can **really** see the progress of your work, then, and I think > that only then, make sense to finish up the details of that and that > other string that show up still untranslated. > > I know that my current proposal has quite a few rough edges and that it > can be put up-side down with some arguments or points of view, but > having in mind this new translation teams, or even teams that get > usually at 100%, having this small sets of modules makes it more > practical to see what's currently left, what's really urgent and what > can be delayed for later... > > > ON SMALL MODULES AND METRICS > Another think that I had in mind when creating this new proposal was to > have a way to, at release notes time, say that not only 50 languages are > considered supported, but we could expand that on: > - languages with accessibility support: above 80% on accessibility set > - languages with developer support: above 80% on the 3 development > categories > - languages with basic support: above 80% on Core and Core Apps > categories > - languages with functional support: basic support + 80% on Apps and > Core Backend categories > - languages with complete support: functional + Utilities, > Accessibility, Apps Extras, Games and Backend categories > - languages with full support: everything translated (as it is now) > > That way, with this splitting, some translation teams that could have > the desire to start translating the accessibility category (because > there people on that language with disabilities and they need to have it > first) could still be recognized. > > The marketing team could do campaigns about developing on GNOME and that > it's really easy because XX languages are supported on the development > tools. > > You get the idea, right? > > ON STRINGS FROM LIBRARIES > I think that it would make sense to have a way to show that a module X > (say epiphany) depends on strings that comes from Y, Z, A and B (for > epiphany: gtk+, webkitgtk, libsoup, gcr...). > > That way, if a translator really wants to go for 100% translation > coverage of a given application (s)he can already see it from the module > page itself. > > > Sorry for the long mail, but was meant mostly to put some emphasis that > the proposal is not just a random thought when taking a shower, I've > been thinking on it for at least a month or so and have come back to it > for at least a week daily moving pieces around and thinking about the > category names and so on. > > That does not mean that modules can not be changed around, of course > they can be, but I hope that, at least the categories, are well thought > enough and will not be completely discarded :) > > Happy translating and prioritizing! > > [1] https://live.gnome.org/TranslationProject/SplittingModules > [2] https://bugzilla.gnome.org/show_bug.cgi?id=680843 > -- > Gil Forcada > > [ca] guifi.net - una xarxa lliure que no para de créixer > [en] guifi.net - a non-stopping free network > bloc: http://gil.badall.net > planet: http://planet.guifi.net > > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-i18n > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modules split proposal (yeah, another one, sorry)
On Sat, Oct 13, 2012 at 4:39 AM, Gil Forcada wrote: > I know I know, we have to tackle that point ... What I was trying to say > was that instead of keeping in the same category the apps and its > libraries (for completeness) if we split them in different categories, > we allow the translators do their job for the most important things > first, and later, once the main UI is completely translated they can > move onto the libraries. > > Still, with this dependency declaration we can allow a translator to > really translate everything that needs to have, say Nautilus, show all > strings, no matter where they come from. Yes, I really do like what you are trying to do. I'm sorry for beating the WebKitGTK+ drum incessantly, but it's importance stems from the fact that web-browsing is one of the most common user activities (and web-errors are common) and so the visibility of the WebKitGTK+ strings is unusually high and will have an out-sized impact on user perception of the L10n experience. I very much like the idea of being able to declare dependencies. Are you thinking of maintaining this manually or through one of the dependency checking mechanisms used by package install processes? There would seem to be distinct advantages and shortcomings to both approaches. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Workflows for DL-Transifex co-hosted PO files.
Gnome i18n folks, There is something I don't really understand about the preferred workflow for modules listed in Damned Lies that are actually hosted on external platforms. Let me cite just one module as an example. The accountsservice module is listed in Damned Lies http://l10n.gnome.org/module/accountsservice/ it is in the "freedesktop.org (non-GNOME)" Release Set It is clearly annotated (and linked) that it's L10n is hosted on an external platform, in this case it is hosted at Transifex. https://www.transifex.com/projects/p/accountsservice/resource/accounts-servicepot/ Scenario A: The project has matching languages present on DL and Transifex (e.g. en_GB). Obviously, the "right" thing to do is to upstream the PO file to Transifex. However, what is the "right" thing to do in DL? Should the PO file be committed to DL? This would at least update the statistics and prevent duplicate effort, but how would conflicts between DL and Transifex L10n be handled and resolved? If the right thing is to *not* commit in DL, when and how do the upstreamed PO files get loaded from Transifex to DL to mark the module as completed (avoiding duplicate work) and to update the stats in DL? Scenario B: A language exists in DL, but not in the Transifex upstream, e.g. Burmese (Myanmar). Obviously it would be desirable, but is it absolutely necessary to create a corresponding language project upstream in Transifex? Would a DL-committed PO result in the L10n being used or would it be ignored because no corresponding upstream PO exists? Thanks to anyone who can help clarify these questions for me. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: git clone
On Mon, Oct 22, 2012 at 9:25 PM, Khoem Sokhem wrote: > Hello Daniel, > > Thank you for your point, It works for me. So I have to check out one by one > (gnome-terminal, gnome-desktop, gnome-games). > > It is possible if I want to check out one folder which has all files for > translation, no need to check out one by one? If you just want a copy of the current PO files, you can go Release Set by Release Set and use the links at the bottom like this: http://l10n.gnome.org/languages/km/gnome-3-6/ui.tar.gz http://l10n.gnome.org/languages/km/external-deps/ui.tar.gz http://l10n.gnome.org/languages/km/gnome-gimp/ui.tar.gz http://l10n.gnome.org/languages/km/gnome-extras-stable/ui.tar.gz CJL ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
WebKitGTK+ i18n
In theory a fix has been landed to allow WebKit GTK+ i18n to land in Damned Lies. https://bugs.webkit.org/show_bug.cgi?id=67580 Can someone please follow up on this, I'm not sure when the Damned Lies server does it's refreshes, but I saw no change when I just checked. http://l10n.gnome.org/module/webkit/ Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: WebKitGTK+ i18n
On Wed, Oct 24, 2012 at 2:46 AM, Claude Paroz wrote: > I had to manually intervene on the server to update the SVN repo, but > now it seems to produce a correct POT file! > > I'd like to thank you Chris for your perseverance to solve this issue, > and also Martin Robinson for his contribution. I'd like to thank Claude and Martin as well for teaming up to work on this long overdue bugfix. I would like to make an appeal ot all language teams to work on completing the WebKitGTK+ PO files and submitting them via vertimus. http://l10n.gnome.org/module/webkit/ There is a further step needed t oget them upstreamed (posting completed PO files as tickets on the webkit tracker, but having complete PO files is the first step. Although it is not tagged is such a way as to draw attention, WebKitGTK+ is very important to a fully localized Gnome web-browsing experience (i.e. Epiphany and Sugar Browse). I think we can all agree that a localized web-browser is essential. The following collection of tickets filed in the GNOME Bugzilla would suggest that Epiphany developers share the concern that I have about the current status of WebKitGTK+ L10n, and now we finally have a chance to close these! https://bugzilla.gnome.org/buglist.cgi?quicksearch=610094%2C+610095%2C+610102%2C+610103%2C+610106%2C+610109%2C+610110%2C+610111%2C+610112%2C+610113%2C+610115%2C+610118%2C+610120%2C+610125%2C+610128%2C+610129%2C+610135%2C+610138%2C+610139%2C+610142%2C+610144%2C+610145%2C+610146%2C+610147%2C+610149%2C+610150%2C+610151%2C+610153%2C+610155%2C+610158%2C+610159%2C+610160%2C+610161%2C+610162%2C+610163%2C+610164%2C+610165 Thank you for your attention to this matter. Warmest Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: WebKitGTK+ i18n
If your team is not using the vertimus workflow (or even if they are), please post your completed PO file for WebKitGTK+ as an attachment to a ticket in the webkit tracker. https://bugs.webkit.org/ Thanks for your attention to this matter. cjl On Wed, Oct 24, 2012 at 10:21 AM, Chris Leonard wrote: > On Wed, Oct 24, 2012 at 2:46 AM, Claude Paroz wrote: >> I had to manually intervene on the server to update the SVN repo, but >> now it seems to produce a correct POT file! >> >> I'd like to thank you Chris for your perseverance to solve this issue, >> and also Martin Robinson for his contribution. > > I'd like to thank Claude and Martin as well for teaming up to work on > this long overdue bugfix. > > I would like to make an appeal ot all language teams to work on > completing the WebKitGTK+ PO files and submitting them via vertimus. > > http://l10n.gnome.org/module/webkit/ > > There is a further step needed t oget them upstreamed (posting > completed PO files as tickets on the webkit tracker, but having > complete PO files is the first step. > > Although it is not tagged is such a way as to draw attention, > WebKitGTK+ is very important to a fully localized Gnome web-browsing > experience (i.e. Epiphany and Sugar Browse). I think we can all agree > that a localized web-browser is essential. > > The following collection of tickets filed in the GNOME Bugzilla would > suggest that Epiphany developers share the concern that I have about > the current status of WebKitGTK+ L10n, and now we finally have a > chance to close these! > > https://bugzilla.gnome.org/buglist.cgi?quicksearch=610094%2C+610095%2C+610102%2C+610103%2C+610106%2C+610109%2C+610110%2C+610111%2C+610112%2C+610113%2C+610115%2C+610118%2C+610120%2C+610125%2C+610128%2C+610129%2C+610135%2C+610138%2C+610139%2C+610142%2C+610144%2C+610145%2C+610146%2C+610147%2C+610149%2C+610150%2C+610151%2C+610153%2C+610155%2C+610158%2C+610159%2C+610160%2C+610161%2C+610162%2C+610163%2C+610164%2C+610165 > > > Thank you for your attention to this matter. > > Warmest Regards, > > cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
en_GB commits please
I've got a big stack of en_GB Po files waiting for commit http://l10n.gnome.org/languages/en_GB/all/ui/ I've pinged the committer (Bruce Cowan, he's busy) and the maintainer (Bastien Nocera, no response). I'd love to get these pending commits cleared away so I can do a better job of focusing on new files. I personally don't think one should necessarily commit one's own work (if other options are available), but I would be wiling to act as another en_GB committer if that is the best way to move this backlog forward. Please advise. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: pulseaudio
On Mon, Nov 5, 2012 at 3:48 PM, Peter Mraz wrote: > we have in transifex translated pulseaudio but in DL we see 0% > This is a frequent issue with externally hosted L10n files, not only pulseaudio (from Transifex), but I think also freedesktop packages from the Translate Project. I would simply like to understand the process of synching up DL with externally-hosted packages in general. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GCompris translation update
On Mon, Nov 12, 2012 at 9:17 AM, Bruno Coudoin wrote: > > Hi, > > Some translations are not yet ready but close. The new release is delayed > to Wednesday 14th. > > Let me know if you need more time. I prefer to slip a couple of days the > release if this brings in more translations. > > Bruno. Dear Localizers, Please take a look at your language status in GCompris and take advantage of this opportunity to land more strings and ideally finish it to 100% completion. http://l10n.gnome.org/module/gcompris/ Sugar Labs re-packages GCompris games for the millions of XO laptops in the hands of children around the world and we are excited about getting the latest from the awesome GCompris team out there, but we need your help to make sure it is translated into as many languages as possible for the upcoming release. Sugar Labs hosts a local (temporary) copy of the GCompris PO file for a few teams that are only active locally (or not present at all on GNOME Damned Lies). Fortunately Spanish is already complete and ready for our large deployments in Latin America, as well as serving as a critical bridging language for our efforts in the indigenous languages of the region. http://translate.sugarlabs.org/projects/GCompris_temp/ French and Portuguese (not yet complete) are also important bridging languages or "languages-of-instruction" in places like Haiti, Francophone Africa and Portuguese-speaking São Tomé and Príncipe in Africa, where there are small deployments that would benefit greatly from access to these wonderful educational games. There are hundreds of XO laptops in Thailand and Vietnam and thousands in Nepal and Rwanda as well as small independent efforts all over the world http://olpcmap.net/ Please help Sugar Labs spread the goodness that is GCompris to the corners of the Earth by joining in a worldwide "sprint to the finish" in your language before the upcoming release. Warmest Regards cjl Sugar Labs Translation Team Coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GCompris translation update / Release delayed again
On Wed, Nov 14, 2012 at 7:02 PM, Bruno Coudoin wrote: > > Hi, > > Thanks a lot for your efforts, I again got some request from translators > to delay the release. > > I set the new date to Sunday 18th. > > Since there are usually a lot of feedback after a new release, we can > expect to have to make a new one within a month or so. Thus it is a good > opportunity to work on an outdated translation. Think also to publish in > your language community the following page on which we describe what is > needed to create a voice set for GCompris. > http://gcompris.net/wiki/Voices_translation > > PS: It make me think that I should maintain a web page showing the > result of our check_missing_voices.pl tool for each language. > > Bruno. Bruno, Have you estimated the size of the localized ogg files versus (for example) using a smallish voice synthesizer like e-speak or even festival? Just wondering because it seems to me like the ogg files could add up quickly. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GCompris translation update / Release delayed again
On Fri, Nov 16, 2012 at 2:41 AM, Bruno Coudoin wrote: > > Hi, > > I made a test a few years ago and was not satisfied. > > For GCompris our requirements are: > > - A very good quality, GCompris is used in schools. > - Support for many langu> > > Le mercredi 14 novembre 2012 à 21:41 -0500, Chris Leonard a écrit : >> >> Have you estimated the size of the localized ogg files versus (for >> example) using a smallish voice synthesizer like e-speak or even >> festival? >> >> Just wondering because it seems to me like the ogg files could add up >> quickly. > > > age and some rare one > - Multi-platform > - Free Software. > > Concerning the size, yes it takes room but nowadays disk are cheap. On > GNU/Linux, users can just pick the voice set they are interested in. > > Bruno. Ok, just wondering. As you may know, in Sugar we are currently using e-speak for TTS, but I can't claim to be very happy with it's voice quality or the ease of creating new voices to cover the indigenous or minority languages that are so important to us.. On the other hand, size is a big deal for our XO users, so ti's a trade-off we are currently willing to make. I just wanted to hear your thoughts on the matter as GCompris and Sugar share a lot of common goals and challenges. Warmest Regards, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: EasyTAG translations, source string improvements
On Sat, Dec 1, 2012 at 5:20 AM, David King wrote: > I applied some minor string fixes in my preparation for the move and for a > new release, and while taking a cursory look over the source strings, there > are many that could do with further improvement. Is there a good way to do > this to minimise time spent by translators? 1) Given that you span Windows and Linux installs, it may be unavoidable to maintain a list of language names (and character sets) internally, but it would be very helpful of you would conform those strings to their specific appearance in the relevant ISO code set PO files to enhance utility of translation memory tools. e.g. use language names as they appear in http://translationproject.org/POT-files/iso_639-3.40.pot or http://translationproject.org/POT-files/iso_639_3-3.40.pot rather than your own constructions like msgid "(Hungarian translation)" I would also like to suggest that checking how other projects phrase certain common strings by doing an English>English look-up in http://www.open-tran.eu/ and using the most common form is also something that localizers would appreciate. Including multiple small variations (Capitalization, punctuation, etc.) of the same basic string solely for some arbitrary sense of aesthetics should be avoided e.g. msgid "Album Artist:" msgid "Album Artist" Just my two cents. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
