Re: New team for Dari (prs)
"Roozbeh Pournader" <[EMAIL PROTECTED]> writes: > On Mon, Jun 23, 2008 at 9:49 PM, Mazdak Kiani <[EMAIL PROTECTED]> wrote: >> My language ISO 639-3 code is prs: >> >> http://www.sil.org/iso639-3/documentation.asp?id=prs >> http://www.ethnologue.com/show_language.asp?code=prs > > When we can use ISO 639-1 language codes, we should use those. ISO > 639-3 should only be used when a code does not exist. At least such "should" is not documented on GNOME's wiki. > Locale projects, including Unicode CLDR, use fa_AF for Dari. For > example, see here: According to Wikipedia (http://en.wikipedia.org/wiki/Dari_%28Persian%29) this Dari language is also spoken in Pakistan, Tajikistan and Turkmenistan. Should Dari speakers in those countries use country code _AF as their locale? Isn't such usage problematic in many ways? Therefore I argue that technically it is better to use three letter language codes if ISO standard has assigned a separate code, because then there is no disambiguity of using country codes etc. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Odd instructions for Git?
Hi, I was reading http://live.gnome.org/TranslationProject/GitHowTo and noticed that it says "It is customary in Git to go for small commits; if you have more than one file, commit them separately, with a descriptive commit message for each commit. For example, if you edit the Makefile.am file for DOC_LINGUAS or the LINGUAS file, it is good to commit the as" However for me this sounds like contradicting very basic rule of version control usage that each commit should contain all logically relevant changes together. For example when committing initial translation, I think only sane solution is to commit first version of po file together with Makefile/LINGUAS change, because those belong logically together. However now Wiki instructs to work in different way. Are we really changing this kind of conventions to adhere some strange Git customs? -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String change in Evince
Hi, There is one string change in Evince as I fixed misspelling of 'appropriate'. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GDM string "%x" and c-format in po file
Hi,
I was about to update gdm's translation, and noticed that only change
was string "%x" which was already translated but the old translation did
not have "c-format" marker for msgid. Because this string goes to
strftime, not to printf, I think this should not have c-format. And if I
translate is at localized preferred date format, I get msgfmt validation
errors. On the other hand if every translation team trusts %x to do
correct thing automatically, this string does not need translation...
I think following change is correct fix for this, but we are now in code
freeze right? The diff does not change code but only comments. Is this
enough important from l10n perspective to get more visibility, is this
an issue to many teams or should I just use no-op %x translation?
diff --git a/gui/simple-greeter/gdm-clock-widget.c b/gui/simple-greeter/gdm-cloc
index 9008e6d..b3e6da8 100644
--- a/gui/simple-greeter/gdm-clock-widget.c
+++ b/gui/simple-greeter/gdm-clock-widget.c
@@ -83,6 +83,7 @@ update_time_format (GdmClockWidget *clock)
clock_format = _("%a %l:%M:%S %p");
/* translators: This is the time format to use for the date
+ * xgettext:no-c-format
*/
tooltip_format = _("%x");
} else {
@@ -91,6 +92,9 @@ update_time_format (GdmClockWidget *clock)
*/
clock_format = _("%a %l:%M %p");
+/* translators: This is the time format to use for the date
+ * xgettext:no-c-format
+ */
tooltip_format = _("%x");
}
--
Tommi Vainikainen
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GDM string "%x" and c-format in po file
Johannes Schmid writes: > I guess you should file a bug and ping the gdm maintainers. Now filed: https://bugzilla.gnome.org/show_bug.cgi?id=613306 -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[Tomboy] String change announcement
Five strings in Tomboy were fixed from using string concatenation to variable substitution to make translations usable. http://bugzilla.gnome.org/show_bug.cgi?id=654883 -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: bug 551859 - translating aisleriot card movement hints
Vincent Povirk writes: >> If proper gettext context is not supported, an old workaround is to use >> >> msgstr "nominative|Queen of Spades" >> >> and then have the programme strip off the "nominative|" part. >> Although this is not considered a very good solution. Also it would >> be necessary with a comment instructing translators to ignore the part >> "nominative|". > > I, er, don't think we can do comments either. Yes you can. There is already quite much translator comments in the Scheme files, e.g. games/terrace.scm: (define variation-names (list ; Translators: this string is the name of a variant of this game. If there is an established standard name for this game or game variant in your locale, use that; otherwise you can translate this string freely or literally, at your option. (_"Terrace") This comment "; Translators: ..." shows up in the po files for the translators by the current tool chain. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Don't commit without permission
On 2005-02-06T20:00:42+0200, [EMAIL PROTECTED] wrote: > I'd like to remind all translators that *all* commits to anything > else than the po files of your own language requires permission. > This is the same policy that we've always had, and which should have > been explained to all translators that have CVS accounts, but > apparantly¹ there needs to be a reminder sent out. I'm here the guilty one, and I can confirm that my common sense was overriding commit policy. Sorry. > In other words, if you want to commit a change, such as a fix for a > bug in a module, you need to ask the maintainer of that module for > approval first. In a similar way, if you want to commit a change, no > matter how trivial, to translations other than your own, you will > need to ask the owner of that translation or the translation > coordinator of that language for approval first. And what I did was for *.po apply s/translator-credits/translator_credits/ to decrease workload of most translators as it was only string change needing attention for many translators. Of course now I see that I wasn't careful enough as you see from that bug. But also with this kind of commit policy helping other translators is not just possible (asking permission for such trivial changes is more work than just leaving it up to each translator). And yes, I can and will work according to commit policy here on even while working with other kind of commit policy in some other repositories. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
"Openoffice" module in translation statistics
Hi, I've noticed that HEAD/extras lists module "openoffice". However checking out the module you can notice in ChangeLog that module has been renamed to "ooo-build". So maybe translation stats pages should list that ooo-build module instead of openoffice. Also module renaming has been done long time ago and after that new translations has been committed to old repository. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
UTF-8 io in messages (was: Re: po file for zh_TW)
On 2005-02-24T23:54:41+0200, [EMAIL PROTECTED] wrote: > You can put valid UTF-8 characters (such as ©) in translateable > messages, but there are some things to consider. See > http://bugzilla.gnome.org/show_bug.cgi?id=99005 for the details. > > Among some things it requires a recent enough gettext and intltool > version, and that a special keyword be added to the top of the > POTFILES.in file. Also, only characters that are supported in most > fonts should be added, but I think it's safe to assume that © is > such a character. For me it seems that po file is okay, but still the translation for this string is not visible. I've tested this with Evince, and the string with © shows untranslated even though po file contains it translated. This is my self compiled (jhbuild) Evince with GNOME 2.10 branch from CVS. Other libs (libc etc.) are from Debian sarge, and some versions are following: gettext (GNU gettext-runtime) 0.14.1 intltool-update (intltool) 0.33 Is this global problem or should it really work? I didn't notice anything special from the bug report what could be a problem. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Fast User Switch Applet Translations
On 2005-04-13T12:08:51+0300, [EMAIL PROTECTED] wrote: > Everything about the i18n build *should* work, and there is a "Fast > User Switch Applet" bugzilla product as well. Thanks in advance. po/POTFILES.in and POTFILES.skip should contain every source file. You will get nice warning and instructions how to fix this if you run intltool-update --maintain in fusa's po directory. There was filenames such as testapp.c which maybe should be in .skip, but I don't know for sure. I'll check if I've time to make translation for my language... -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Evince proposed module?
Hello, it is a bit unclear for me who and how it is decided what is included in the next GNOME release, and who can propose modules. Thus I'd like to know if Evince will be added to list of proposed modules or should it already be on that list? Will it also deprecate ggv and gpdf modules? -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
gdm2 string changes
Hi, I've committed many string changes to gdm2. Here is a list of most important changes to help translators possibly quickly skip many fuzzy strings. machine -> computer program -> application or command superuser -> root gdm, Gdm -> GDM For discussion about these string changes, see http://bugzilla.gnome.org/show_bug.cgi?id=310453 > HTH, -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Evince converted to gnome-doc-utils
Hi, I have converted Evince to gnome doc utils. There was no existing translations, but now you are starting to feel like you should make one for *your language*. :-) -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Feature & module freeze result?
Hi, according to this mail on the release team's list: http://mail.gnome.org/archives/release-team/2005-July/msg00108.html > Evince and gnome-keyring-manager got accepted and ggv+gpdf were dropped because evince replaces those, and proposed cups things were rejected. AFAIK services-admin is actually part of gnome-system-tools and is included in translation statistics of it. I hope this mail helps translations teams to concentrate on right modules until we get some kind of 'official announcement'... -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Zenity now uses gnome-doc-utils
On 2005-07-25T08:34:05+0300, [EMAIL PROTECTED] wrote: > I've recently translated zenity for Gnome 2.10, and yesterday zenity > for Gnome 2.12. Do I need to do anything about it? Please follow instructions at http://live.gnome.org/GnomeDocUtilsTranslationMigration > -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Zenity now uses gnome-doc-utils
On 2005-07-26T10:20:37+0300, [EMAIL PROTECTED] wrote: > Does this really apply to my translation? I've only translated the > single .po file listed on the l10n page for my language for each of > Gnome 2.10 and 2.12. I haven't translated any documentation yet. If you have translated only the application, not the documentation, there nothing you need to do. Sorry for not reading you enough carefully at first... :-) -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GDM migrated to gnome-doc-utils
Hi, Yesterday night I committed the migration of GNOME display manager (aka GDM in CVS module gdm2) to gnome-doc-utils. I did not migrate the translations (de es fr it sv ja ko zh_CN zh_HK zh_TW). Help is welcome for this. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gnome-doc-utils ?
On 2005-08-05T12:31:59+0300, [EMAIL PROTECTED] wrote: > Maybe I missed something. Can somebody explain what gnome-doc-utils > is for, and how to change applications to use it?? Main thing from translators point of view is that with gnome-doc-utils we can translate manuals as PO files (similar to program messages), and keeping translation in sync is also easier. However quoting some propaganda :D from http://live.gnome.org/GnomeDocUtilsMigrationHowTo """ Advantages 1. You get a build system that works for you 2. You get translated docs which are easier to maintain 3. You get translation status pages for you docs: http://kvota.net/doc-l10n/by-modules.html#your-module 4. Everybody starts loving you 5. Girls start loving you (FIXME: do they?) ... """ The URL I mentioned also contains instructions for migrating modules to use gnome-doc-utils. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translating the GNOME 2.12 release notes
On 2005-08-18T17:19:14+0300, [EMAIL PROTECTED] wrote: > The release notes will be ready for translation on August 31st, > giving you one week for translation before the release on September > 7th. I just wonder if any of you have heard about HTTP content negotiation? Content negotiation is a way for the web browser to send accepted languages in a HTTP request and get the best translation (according to user's preferences) as return. For example Debian's website uses this technique, and you can read more at http://www.debian.org/intro/cn > Of course there are some proxies et cetera in wild which have broken support for this technique, and therefore sometimes at least Debian gets feedback because of badly configured browsers or broken proxy servers, but IMHO the technique works well. As a translator this is interesting question for me because having a link "http://www.gnome.org/start/2.12/notes/"; select language automatically would increase visibility of translations as users no longer need to manually select translation every time. To use such technique, the pages need to be named in a way that HTTP server's content negotiation module understands those to be same page, and content negotiation module loaded -- that should be enough. In Apache it would mean that when english page is notes/index.html, then Finnish translation is index.fi.html (or index.html.fi depending on some settings), and French translation is index.fr.html (or index.html.fr). Then user accesses URL http://www.g.o/s/2.12/notes/ or .../notes/index and gets version of the page according to his/her browser settings. (Technically it sends Accept-Language header in HTTP request.) -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Gucharmap migrated to gnome-doc-utils
Hi, I've just applied a patch to gucharmap, which migrated it to use gnome-doc-utils for help system. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Commit policies and autogenerated changes
Hi, It is currently bit unclear to me what kind of policies are for translation maintenance and file touching (soft) permissions. It seems that in some modules maintainers, when making release, run "make update-po" and commit after that. However such changes are autogenerated (anyone can run that "make update-po"), and thus add no value to cvs history. If translators want to look at history of translation, there is rather much "released x.y.z" in cvs history which hides useful content... Some other module maintainers instead don't commit those changes, and thus translators can really "own" the translations. This is the way I think it should be in every module. Is there any general commit policy regarding this? Is it up to maintainers of the module or can team leader tell to not to touch translations under their supervision? -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: committing updated po files
On 2005-09-20T18:44:55+0300, [EMAIL PROTECTED] wrote: > Tomasz, why did you need to do this everywhere? :( I really hope > there are some good reasons for this. Anyway, please revert all these > changes. Was there ever any conclusion for this thread? I see that Thomas has done more this kind of commits after last message in the thread as can be seen from http://cia.navi.cx/stats/author/kloczek > Was this discussion moved to somewhere else than gnome-i18n? -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: release notes: first draft
On 2006-03-07T11:34:25+0200, [EMAIL PROTECTED] wrote: > GStreamer 0.10 will also allow users to take advantage of multimedia > plugins distributed by 3rd party vendors to offer support for licensed > codecs for which no legal plugins are available. These may include > support for AC3, WMA, MP3 and more. A licensed, yet freely available, > MP3 plugin for GStreamer 0.10 has already been made available by > Fluendo, a long-time supporter of GStreamer. For me this seems bit U.S. centric. In many countries (even Western countries) reverse engineering is allowed. In many more countries there are no patents restricting those file formats. Therefore codes/plugins are most likely "illegal" only in U.S. and some other countries, but not all over the world. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
gcalctool migrated to gnome-doc-utils
Hello, gcalctool has been migrated to use gnome-doc-utils. There is still some translations (bg de es fr it ja ko sv zh_CN zh_HK zh_TW) todo. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: strange language in the status pages
On 2006-03-29T14:58:04+0300, [EMAIL PROTECTED] wrote: > Browsing through the status pages (we have 100 languages now!) I found a > strange language that I haven't heard of before: nl-1 > Looking closer I see that there's only one module translated, and it's > an old version of a gucharmap module translated to Dutch (nl) That nl-1.po was committed by Vincent van Adrighem many days ago. Can you Vincent explain us curious people what is that language?-) It is only in gucharmap branch gnome-2-14, and it is not listed in configure.ac ALL_LINGUAS. So was this some kind of mistake or not? What is the difference between Dutch (nl) and nl-1? Here is some lines from ChangeLog: 2006-03-07 Vincent van Adrighem <[EMAIL PROTECTED]> * nl.po: Translation updated by Tino Meinen. 2006-03-06 Vincent van Adrighem <[EMAIL PROTECTED]> * nl-1.po: Translation added by Sebastien Bruggeman. > I've no idea how that language ended up in the status pages, but I think > it can be savely removed (bringing the number of languages back to 99) It has ended there because status scripts grab all .po files. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Guarani Nhandeva translation
On 2006-04-07T04:31:50+0300, [EMAIL PROTECTED] wrote: On 4/6/06, Boca <[EMAIL PROTECTED]> wrote: > >> Thanks for the explication about the languages codes. So, we decided to >> choose the gn_BR code, ok? Could be? > > Christian, can gn_BR be used or just gn is preferable? (Matheus, this > is just to make it clear with GTP coordinators) Hello Boca, just before Christian or someone else asks these same questions about the code, can you explain to us (because you known much more than other people here) where is Guarani spoken and what kind of dialects or variants there exists. If I understood correct Nhandeva is the name of the language in Guarani and Guarani is the name of the language in English. English wikipedia does not tell me anything about dialects[1]. If there is only one language that is almost universally spoken similarly, then it must use code "gn". But if Guarani in Brazil is somehow different than Guarani spoken somewhere else, then "gn_BR" is the correct code. So please tell us about dialects and/or regions and rationale why you would like to use code gn_BR, or should you use simply gn. [1] http://en.wikipedia.org/wiki/Guaran%C3%AD_language -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: libgnomeui.po - msgfmt test failure.
On 2006-04-13T07:58:36+0300, [EMAIL PROTECTED] wrote: > msgfmt -cv libgnomeui.po -o /dev/null > > th output is: > > libgnomeui.po:17:7: parse error > msgfmt: found 1 fatal error Which version of msgfmt you are using? For me the attached file works fine: $ msgfmt -cv libgnomeui.po 344 translated messages. $ LANG=C msgfmt --version msgfmt (GNU gettext-tools) 0.14.5 Copyright (C) 1995-1998, 2000-2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Ulrich Drepper. -- Tommi Vainikainen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
