Re: gnome-doc-utils strings (was Re: New module : GNOME Power Manager)
On Thu, 14 Jul 2005 14:04:07 +0930, Clytie Siddall wrote: > It is essential to know the purpose of the string. Background like: > ___ > Type: menu item > Function: brings up a dialogue which allows the user to modify > currently-highlighted text > Original: Edit > ___ > is much better than just "Edit" on its own. The less information in > the string, the more explanation we need. This would be a substantial burden to the developers. Absolutely off-topic, for which I apologise: I've noticed that you're quite actively translating GNOME and debconf templates. How can you possibly do this effectively if you are not running a GNU system? Apple Mail, AFAIK, runs only on the proprietary system MacOS X. We had one translator in the past who was blindly translating on Windows and the result was pretty painful -- all translations were a mess. That usually happens when there is no possibility to test the translation. Most of the code is very well commented, so if you doubt for a particular string you can always checkout from CVS and open the relevant file in another buffer of Emacs ;-) Or you can always check how other people have translated it (f.i. our team is "using" the experience of the Russian, Serbian and Macedonian teams). There are some strings which are ambigous, but you can always test your translation and make the right decision. Asking the developers to comment every string in detail sounds crazy (at least to me). P.S. Have you tried GNUMail.app? -- Yavor Doganov JID: [EMAIL PROTECTED] Free Software Association - Bulgaria http://fsa-bg.org GNOME in Bulgarian! http://gnome.cult.bg ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Finding context for strings (was Re: gnome-doc-utils strings)
Hi Yavor, Today at 9:12, Yavor Doganov wrote: > On Thu, 14 Jul 2005 14:04:07 +0930, Clytie Siddall wrote: > >> It is essential to know the purpose of the string. Background like: >> ___ >> Type: menu item >> Function: brings up a dialogue which allows the user to modify >> currently-highlighted text >> Original: Edit >> ___ >> is much better than just "Edit" on its own. The less information in >> the string, the more explanation we need. > > This would be a substantial burden to the developers. Actually, we should try to explore how to make that not be a burden to developers yet get that information. I already have some ideas for that, but I'm not spending too much time actively hacking on it. For example, many applications use Glade files. With them, we can do many interesting things. For instance, I was planning on doing the following: — load Glade file in, separate segments into "visible at any one time" — load a translation and check for conflicting accelerators — suggest any of the strategies for resolving conflicting accelerators Another use would be to extract such "context" information as Clytie suggested. These are all interesting (and not too hard) projects for anyone having some spare time (I'd be willing to give a lot of help and pointers if needed). Anyone can start by subscribing to gnome-i18n-tools[1] list (didn't have any traffic so far, so I want to activate it), and lets discuss such tool development there. [1] http://mail.gnome.org/mailman/listinfo/gnome-i18n-tools We should not just say that something is hard and give up, we should instead try to look for solutions for problems we have. Even if it means it will work only for a subset of all translatable programs (i.e. those using Glade), it's still a big win, IMHO. > Absolutely off-topic, for which I apologise: I've noticed that you're > quite actively translating GNOME and debconf templates. How can you > possibly do this effectively if you are not running a GNU system? Apple > Mail, AFAIK, runs only on the proprietary system MacOS X. We had one > translator in the past who was blindly translating on Windows and the > result was pretty painful -- all translations were a mess. That usually > happens when there is no possibility to test the translation. I mostly agree with you, but it's actually possible to run GNU software on MacOS/X (I've ran across numerous mentions of some repository named "fink", etc.). Also, it's up to end users of a translation to deduce how good is it, so lets leave complaining to native vi users and other vi translators. > Most of the code is very well commented, so if you doubt for a particular > string you can always checkout from CVS and open the relevant file in > another buffer of Emacs ;-) Or you can always check how other people have > translated it (f.i. our team is "using" the experience of the Russian, > Serbian and Macedonian teams). These are actually only work-arounds. We want to lower barriers to translation, and while these are all same things that I use, I don't want to make every translator use them: it wastes their time, just like it wastes yours and mine (if you had most entries marked with "button" or "menu item", I guess you'd need to look elsewhere at least a bit less often, and we can get that, as I described). > There are some strings which are ambigous, but you can always test your > translation and make the right decision. Asking the developers to comment > every string in detail sounds crazy (at least to me). Indeed: the goal is to help translators waste less time, but not at the cost of extensively increasing workload of developers. We should meet somewhere in the middle, and that's what we're doing now (we're asking developers to comment on any ambigous messages). Recommended practice is still the following: 1. translate 2. check translation extensively by running translated program, watching for inappropriate translations (out of context), conflicting accellerators Currently, 2nd step is still very hard, so lets try to make it much simpler. Maybe I'm wrong and it's no improvement at all, but why not try it first? Cheers, Danilo ___ 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
Re: Evince proposed module?
tor 2005-07-14 klockan 12:50 +0300 skrev Tommi Vainikainen: > 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. IIRC it's the GNOME Release Team that formally makes a decision, based on community consensus. Modules are to be proposed for inclusion by their maintainers on the desktop-devel-list during the module proposal period. > 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? Honestly, I have no idea. The release team tracks the proposed modules but I cannot find Evince mentioned on http://live.gnome.org/ReleasePlanning/TwoPointEleven/Desktop ... Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Weekly translation status for Gnome 2.10
Translation status changes from 2005-07-07 to 2005-07-14. Total message count has changed from 32563 to 32562. Average change during this period was 0.027%. Top 5 movers of the week: * Persian (up 1.38%, now unsupported) * Vietnamese (up 0.75%, supported) * Estonian (up 0.35%, partially supported) * Macedonian (up 0.24%, partially supported) * Hebrew (up 0.13%, unsupported) Supported languages (more than 80% strings translated). 1. Canadian English (en_CA) 99.99% down 0.01% Dutch (nl) 99.99% down 0.01% Punjabi (pa) 99.99%no change Chinese Traditional (zh_TW)99.99% down 0.01% Danish (da)99.99% down 0.01% German (de)99.99% down 0.01% Serbian (sr) 99.99% down 0.01% Spanish (es) 99.99% down 0.01% 9. Hungarian (hu) 99.98% down 0.01% Gujarati (gu) 99.98% down 0.01% 11. Albanian (sq) 99.97% down 0.01% Brazilian Portuguese (pt_BR) 99.97% down 0.01% British English (en_GB)99.97% down 0.01% Czech (cs) 99.97% down 0.01% Lithuanian (lt)99.97% down 0.01% Portuguese (pt)99.97% down 0.01% 17. Finnish (fi) 99.95% down 0.02% Greek (el) 99.95% down 0.01% 19. Ukrainian (uk) 99.94% down 0.02% 20. Japanese (ja) 99.91%no change 21. Catalan (ca) 99.86% down 0.02% 22. Korean (ko)99.36% down 0.01% 23. French (fr)98.91% down 0.01% 24. Bulgarian (bg) 98.87% down 0.01% 25. Polish (pl)98.50% down 0.01% 26. Norwegian Bookmal (nb) 97.03% down 0.02% 27. Vietnamese (vi)96.86% up 0.75% 28. Russian (ru) 96.08% down 0.01% 29. Swedish (sv) 94.43% down 0.01% 30. Turkish (tr) 90.21% down 0.01% 31. Welsh (cy) 87.56%no change 32. Chinese Simplified (zh_CN) 87.40% down 0.02% 33. Romanian (ro) 86.35% up 0.01% 34. Italian (it) 85.72% down 0.01% 35. Indonesian (id)85.15% down 0.01% 36. Hindi (hi) 83.12% up 0.08% 37. Tamil (ta) 80.61% down 0.01% Partially supported languages (between 50% and 80%). 38. Estonian (et) 75.09% up 0.35% 39. Norwegian Nynorsk (nn) 74.22% down 0.01% 40. Basque (eu)72.89%no change 41. Arabic (ar)71.80%no change 42. Azerbaijani (az) 70.82%no change 43. Xhosa (xh) 70.60% down 0.01% 44. Nepali (ne)66.04%no change 45. Macedonian (mk)66.00% up 0.24% 46. Malay (ms) 63.06% down 0.01% 47. Slovak (sk)62.72% down 0.01% 48. Galician (gl) 60.68%no change 49. Croatian (hr) 59.58% down 0.01% 50. Mongolian (mn) 57.59%no change 51. Bosnian (bs) 57.39%no change 52. Slovenian (sl) 57.20% down 0.02% 53. Bengali (bn) 55.48% up 0.01% 54. Belarusian (be)54.65% down 0.01% Unsupported languages (less than 50%). 55. Persian (fa) 47.83% up 1.38% 56. Thai (th) 45.58%no change 57. Hebrew (he)40.18% up 0.13% 58. Latvian (lv) 33.74% down 0.01% 59. Wallon (wa)23.90%no change 60. Icelandic (is) 21.22%no change 61. Irish Gaelic (ga) 20.50%no change 62. Afrikaans (af) 19.89%no change 63. Malayalam (ml) 17.53%no change 64. Northern Sotho (nso) 17.50%no change 65. Amharic (am) 14.41%no change 66. Serbian Jekavian ([EMAIL PROTECTED]) 14.14%no change 67. Zulu (zu) 13.09%no change 68. Turkmen (tk) 11.54%no change 69. Limburgish (li)11.30%no change 70. Oriya (or) 9.35% up 0.01% 71. Kinyarwanda (rw)9.27%no change 72. Marathi (mr)8.76%no change 73. Yiddish (yi)5.24%no change 74. Esperanto (eo) 4.54%no change 75. Kannada (kn)2.56%no change 76. Telugu (
Weekly translation status for Gnome 2.12
Translation status changes from 2005-07-07 to 2005-07-14. Total message count has changed from 32978 to 32696. Average change during this period was -0.311%. Top 5 movers of the week: * Macedonian (up 3.66%, now partially supported) * Hindi (up 1.93%, supported) * Serbian (up 1.6%, supported) * Vietnamese (up 1.41%, partially supported) * Persian (up 1.25%, unsupported) Supported languages (more than 80% strings translated). 1. Spanish (es) 99.55% up 0.01% 2. Canadian English (en_CA) 99.42% down 0.56% 3. Czech (cs) 98.88% up 0.02% 4. Bulgarian (bg) 98.74% down 0.67% 5. Norwegian Bookmal (nb) 98.48% down 0.64% 6. Danish (da)98.39% down 0.75% 7. Chinese Simplified (zh_CN) 97.53% down 0.67% 8. Dutch (nl) 97.36% down 0.15% 9. Finnish (fi) 96.37% down 0.52% 10. Chinese Traditional (zh_TW)96.15% up 1.24% 11. British English (en_GB)96.13% down 0.75% 12. German (de)95.87% down 0.48% Serbian (sr) 95.87% up 1.60% 14. Japanese (ja) 95.61% down 0.71% 15. Albanian (sq) 95.34% down 0.76% 16. Brazilian Portuguese (pt_BR) 95.04% up 0.50% 17. Punjabi (pa) 95.03% down 0.07% 18. Catalan (ca) 94.75% down 0.74% 19. Greek (el) 94.58% down 0.75% 20. Hungarian (hu) 94.09% down 0.42% 21. Portuguese (pt)93.70% down 0.66% 22. Lithuanian (lt)93.61% down 0.66% 23. Ukrainian (uk) 93.56% down 0.76% 24. Gujarati (gu) 92.75% down 0.77% 25. French (fr)92.56% down 0.76% 26. Korean (ko)92.29% down 0.68% 27. Hindi (hi) 92.18% up 1.93% 28. Polish (pl)91.58% down 0.65% 29. Russian (ru) 90.56% down 0.66% 30. Swedish (sv) 89.72% down 0.68% 31. Nepali (ne)85.73% down 0.71% 32. Turkish (tr) 84.28% down 0.80% 33. Indonesian (id)82.71% down 0.84% 34. Welsh (cy) 82.13% down 0.67% 35. Romanian (ro) 81.25% down 0.83% Partially supported languages (between 50% and 80%). 36. Italian (it) 76.68% down 0.90% 37. Tamil (ta) 75.48% down 0.70% 38. Croatian (hr) 75.39% down 0.71% 39. Estonian (et) 73.78% down 0.14% 40. Vietnamese (vi)71.77% up 1.41% 41. Norwegian Nynorsk (nn) 69.35% down 0.65% 42. Macedonian (mk)68.83% up 3.66% 43. Basque (eu)67.25% down 0.82% 44. Arabic (ar)66.80% down 0.88% 45. Azerbaijani (az) 66.33% down 0.84% 46. Xhosa (xh) 64.63% down 0.75% 47. Slovak (sk)62.95% up 1.12% 48. Malay (ms) 58.74% down 0.88% 49. Galician (gl) 56.67% down 0.86% 50. Bosnian (bs) 53.93% down 0.79% 51. Mongolian (mn) 53.83% down 0.79% 52. Bengali (bn) 51.26% down 0.80% 53. Belarusian (be)50.40% down 0.91% Unsupported languages (less than 50%). 54. Thai (th) 47.82% down 0.39% 55. Persian (fa) 47.38% up 1.25% 56. Slovenian (sl) 38.33% down 0.91% 57. Hebrew (he)38.17% up 0.24% 58. Latvian (lv) 31.32% down 0.56% 59. Wallon (wa)22.31% down 0.88% 60. Irish Gaelic (ga) 19.00% down 0.65% 61. Icelandic (is) 18.99% down 0.98% 62. Afrikaans (af) 17.91% down 1.02% 63. Malayalam (ml) 16.63% up 0.06% 64. Northern Sotho (nso) 15.47% down 1.05% 65. Amharic (am) 13.08% down 0.43% 66. Serbian Jekavian ([EMAIL PROTECTED]) 12.48% down 1.05% 67. Zulu (zu) 11.19% down 1.03% 68. Turkmen (tk) 10.05% down 0.74% 69. Limburgish (li) 9.77% down 0.99% 70. Oriya (or) 9.16% up 0.08% 71. Kinyarwanda (rw)9.03%no change 72. Marathi (mr)8.88% up 0.07% 73. Yiddish (yi)5.14% up 0.03% 74. Esperanto (eo) 3.41% down 1.03% 75. Uighur (ug) 3.26% up 0.01% 76. Kannada (kn)
Re: [Evolution-hackers] Re: String changes for evolution-exchange
> > Most of these strings were already translated as part of evolution- > > exchange changes, but have now been moved to either of evolution or > > evolution-data-server. So, i am not sure if retranslation would be > > needed. Most of these strings should only be in evolution, and we are > > trying to move the remaining strings from evolution-data-server to > > evolution eventually. > > I'll try to migrate all of these translations once POTFILES.in problem > is resolved (I don't want to lose translations because of files not in > there, and I don't know if it's safe to simply > "cat missing >>POTFILES.in"; difference is around 110 strings in > these "missing" files). Was there any particular reason this wasn't done in a more controlled manner, like the gal->evolution and camel->eds changes, which were merged, and so no translations were lost in the end? ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
