Application categories translations in library.gnome.org
Hi, I wonder where the translations for application categoreis, such as Desktop, Accessibility, Accessories, etc. in GNOME Library Users page [1] come from. [1] http://library.gnome.org/users/ For Thai page, they appear to be from very old versions of yelp or gnome-menus translations. (It must be yelp, I suppose.) How can I update them to newer version? Thanks, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Account request
Le vendredi 14 mars 2008 à 11:45 +0100, Robert-André Mauchin a écrit : Hi, I would like to apply for a svn access for the french translation. I've been translating since few releases and my work seems significant enough. I've read FAQ and related stuff, everything should be ok. Having an account will permit the french team to have a second full-time committer after the retirement of Stéphane Raimbault. Thanks in advance for your help, http://live.gnome.org/NewAccounts :-) Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Account request
Hi, I would like to apply for a svn access for the french translation. I've been translating since few releases and my work seems significant enough. I've read FAQ and related stuff, everything should be ok. Having an account will permit the french team to have a second full-time committer after the retirement of Stéphane Raimbault. Thanks in advance for your help, Bob Mauchin. signature.asc Description: Ceci est une partie de message numériquement signée ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Account request
Le vendredi 14 mars 2008 à 11:55 +0100, Claude Paroz a écrit : Le vendredi 14 mars 2008 à 11:45 +0100, Robert-André Mauchin a écrit : Hi, I would like to apply for a svn access for the french translation. I've been translating since few releases and my work seems significant enough. I've read FAQ and related stuff, everything should be ok. Having an account will permit the french team to have a second full-time committer after the retirement of Stéphane Raimbault. Thanks in advance for your help, http://live.gnome.org/NewAccounts :-) I know Claude, but it says « NOTE: This form does not yet work for translation requests. These will be added asap. » So I thought there is a super tricky special thing to do for translator ? Thanks. signature.asc Description: Ceci est une partie de message numériquement signée ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Application categories translations in library.gnome.org
Theppitak Karoonboonyanan wrote: I wonder where the translations for application categoreis, such as Desktop, Accessibility, Accessories, etc. in GNOME Library Users page [1] come from. [1] http://library.gnome.org/users/ For Thai page, they appear to be from very old versions of yelp or gnome-menus translations. (It must be yelp, I suppose.) How can I update them to newer version? They are indeed imported from Yelp 2.18.1; I will change it now to use translations from 2.22.0. Regards, Frederic ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Application categories translations in library.gnome.org
Theppitak Karoonboonyanan wrote: Hi, I wonder where the translations for application categoreis, such as Desktop, Accessibility, Accessories, etc. in GNOME Library Users page [1] come from. [1] http://library.gnome.org/users/ For Thai page, they appear to be from very old versions of yelp or gnome-menus translations. (It must be yelp, I suppose.) How can I update them to newer version? They come from this translation, http://l10n.gnome.org/module/library-web Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Account request
Le vendredi 14 mars 2008 à 12:05 +0100, Robert-André Mauchin a écrit : Le vendredi 14 mars 2008 à 11:55 +0100, Claude Paroz a écrit : Le vendredi 14 mars 2008 à 11:45 +0100, Robert-André Mauchin a écrit : Hi, I would like to apply for a svn access for the french translation. I've been translating since few releases and my work seems significant enough. I've read FAQ and related stuff, everything should be ok. Having an account will permit the french team to have a second full-time committer after the retirement of Stéphane Raimbault. Thanks in advance for your help, http://live.gnome.org/NewAccounts :-) I know Claude, but it says « NOTE: This form does not yet work for translation requests. These will be added asap. » So I thought there is a super tricky special thing to do for translator ? I think it's not true any more. The remaining problem is for team with a coordinator without SVN account. Olav, could you confirm and update the page? The fallback address in case of problems with Mango interface is [EMAIL PROTECTED] Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Application categories translations in library.gnome.org
On Fri, Mar 14, 2008 at 6:16 PM, Simos Xenitellis [EMAIL PROTECTED] wrote: They come from this translation, http://l10n.gnome.org/module/library-web Nope. I had already checked that place before posting. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Ekiga 3.00
Le vendredi 14 mars 2008 à 17:36 +0200, Nikos Charonitakis a écrit : 2008/1/13, Damien Sandras [EMAIL PROTECTED]: Consequently, I think translators should continue working on the gnome-2-20 branch. After GNOME 2.22 is released, I will create a gnome-2-22 branch. we worked on gnome-2-20 branch but greek help translation is not present in gnome 2.22 (el was added to Makefile.am) What happened? Notice that we have now branched and are using gnome-2-22 branch. However: cat help/Makefile.am : [...] DOC_LINGUAS = bg de es fr pt_BR ru sv uk el is not present in DOC_LINGUAS, which explains why it is not included in the tarball. I see somebody just added el to DOC_LINGUAS in the old gnome-2-20 branch 10 seconds ago. Please make sure you are using the gnome-2-22 branch. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Ekiga 3.00
Sorry, it was my mistake. I did the needed changes when i uploaded Greek translation but forgoten to commit Makefile.am. Everything was ok to my local svn copy... So i fixed it now. Thanks Nikos 2008/3/14, Damien Sandras [EMAIL PROTECTED]: Le vendredi 14 mars 2008 à 17:36 +0200, Nikos Charonitakis a écrit : 2008/1/13, Damien Sandras [EMAIL PROTECTED]: Consequently, I think translators should continue working on the gnome-2-20 branch. After GNOME 2.22 is released, I will create a gnome-2-22 branch. we worked on gnome-2-20 branch but greek help translation is not present in gnome 2.22 (el was added to Makefile.am) What happened? Notice that we have now branched and are using gnome-2-22 branch. However: cat help/Makefile.am : [...] DOC_LINGUAS = bg de es fr pt_BR ru sv uk el is not present in DOC_LINGUAS, which explains why it is not included in the tarball. I see somebody just added el to DOC_LINGUAS in the old gnome-2-20 branch 10 seconds ago. Please make sure you are using the gnome-2-22 branch. -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Ekiga 3.00
2008/1/13, Damien Sandras [EMAIL PROTECTED]: Consequently, I think translators should continue working on the gnome-2-20 branch. After GNOME 2.22 is released, I will create a gnome-2-22 branch. we worked on gnome-2-20 branch but greek help translation is not present in gnome 2.22 (el was added to Makefile.am) What happened? regards nikos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Improving things for translators
On Thu, 2008-03-13 at 14:26 +0100, Vincent Untz wrote: Le jeudi 13 mars 2008, à 13:56 +0100, Kenneth Nielsen a écrit : One last item is that more and more teams are now able to translate the documentation, but it's very hard since it's not frozen and can change at the very last minute. Claude suggested on IRC that we add a new documentation freeze for translators: the freeze would start the week-end before the .0 release. This way the documentation can still be updated during the last week before the release and translators have a few days to update the translations. I think it'd make sense to lift the freeze after the .0 release (so documentation can still be updated between .0 and .1) and enforce it again the week-end before the .1 release, and so on. Any comment about this proposal? Vincent Sound great. Maybe a bit more than one week would be nice. If we make it two weeks then we split the UI-string freeze period in two. Essentially giving developers 2 weeks (to update documentation) and translators 2 week to update them. Would that be acceptable to developers ? Regards Kenneth Nielsen It won't work: the documentation is not written by developers, but by the documentation team. And they need more time to update all the documentation in GNOME. If we want to freeze the documentation, it can only be for a very short time at the end of the cycle. Indeed. Documentation writing doesn't really heat up until after the feature freeze, which is roughly half way through our release cycle. That leaves the team three months to update all the documentation. Factor in these facts: 1) Our documentation is out of date, sometimes by as much as a few years. We're still trying to clear the backlog, so to speak, which makes for an even heavier workload. If we ever caught up, we'd be in a better position to make future updates in a timely manner. 2) The desktop release contains 86 documents. Some of them are smallish, but some of them are huge. We add new modules with every release. 3) We have almost no active writers at the moment. Virtually all updates are those that Ubuntu sends upstream. I'm way too busy being a hacker to be a writer. My long-standing policy on documentation freezes is that it's something we want to do at some point, but we're not in a position to do it right now. We need every last second we can get to do documentation. What I would prefer to do, at least initially, is to implement voluntary freezes on documentation. With Pulse (cue dramatic music) we could extract various bits of metadata about status, reviews, and readiness for translation from our documents. Then translators could look at Pulse to see which documents are worth devoting time to, and which are going to change out from underneath them. Whenever we finish a document (cue laughter), we'd mark it as such, and translators would know. Having fully translated documentation is of no use if what was translated was crap to begin with. Garbage in, garbage out. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Improving things for translators
Le vendredi 14 mars 2008 à 16:12 -0500, Shaun McCance a écrit : On Thu, 2008-03-13 at 14:26 +0100, Vincent Untz wrote: Le jeudi 13 mars 2008, à 13:56 +0100, Kenneth Nielsen a écrit : One last item is that more and more teams are now able to translate the documentation, but it's very hard since it's not frozen and can change at the very last minute. Claude suggested on IRC that we add a new documentation freeze for translators: the freeze would start the week-end before the .0 release. This way the documentation can still be updated during the last week before the release and translators have a few days to update the translations. I think it'd make sense to lift the freeze after the .0 release (so documentation can still be updated between .0 and .1) and enforce it again the week-end before the .1 release, and so on. Any comment about this proposal? Vincent Sound great. Maybe a bit more than one week would be nice. If we make it two weeks then we split the UI-string freeze period in two. Essentially giving developers 2 weeks (to update documentation) and translators 2 week to update them. Would that be acceptable to developers ? Regards Kenneth Nielsen It won't work: the documentation is not written by developers, but by the documentation team. And they need more time to update all the documentation in GNOME. If we want to freeze the documentation, it can only be for a very short time at the end of the cycle. Indeed. Documentation writing doesn't really heat up until after the feature freeze, which is roughly half way through our release cycle. That leaves the team three months to update all the documentation. Factor in these facts: 1) Our documentation is out of date, sometimes by as much as a few years. We're still trying to clear the backlog, so to speak, which makes for an even heavier workload. If we ever caught up, we'd be in a better position to make future updates in a timely manner. 2) The desktop release contains 86 documents. Some of them are smallish, but some of them are huge. We add new modules with every release. 3) We have almost no active writers at the moment. Virtually all updates are those that Ubuntu sends upstream. I'm way too busy being a hacker to be a writer. My long-standing policy on documentation freezes is that it's something we want to do at some point, but we're not in a position to do it right now. We need every last second we can get to do documentation. Hi Shaun, I'm convinced that a 3 day-freeze in a six months release won't change anything to the current lack of writers for docs. It's just a timing matter. As a translator, what I would absolutely prevent, it's what happened with the platform-overview document (excellent, by the way!) you updated some minutes/hours before releasing. We worked many hours on the translation of this document, Vincent and I, just to see it being only partially translated in GNOME 2.22 :-( If a freeze would have been in place, you probably would have planned to update the doc three days before. Don't take it as a personal attack, you had the right to do it that way. What I would prefer to do, at least initially, is to implement voluntary freezes on documentation. Sorry, but a voluntary freeze means nothing to me. Either a normal freeze or nothing. With Pulse (cue dramatic music) we could extract various bits of metadata about status, reviews, and readiness for translation from our documents. Then translators could look at Pulse to see which documents are worth devoting time to, and which are going to change out from underneath them. Whenever we finish a document (cue laughter), we'd mark it as such, and translators would know. Damned-lies already produces stats about new strings to translate. And we can assume that new strings committed in SVN means they are worth to be translated also. OK, it may also be work in progress, but in this special case, a simple mail to gnome-i18n will do the job. Having fully translated documentation is of no use if what was translated was crap to begin with. Garbage in, garbage out. Of course, but we can say the same for programs. That doesn't prevent in any way to put a freeze in place for UI translations. BTW, the lack of writers seems to be a real problem now, even if we also see some very good doc practices at time (e.g. gcalctool). But that'd be the subject of another thread. Cheers, Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: ATK, GAIL, AT-SPI branched for 2.22 (was: ATK branched for 2.22)
Le vendredi 14 mars 2008 à 10:45 +0800, Li Yuan a écrit : Hi, ATK has been branched for GNOME 2.22 with the release of 1.22.0. ATK 1.22.0 sources represent the beginning of the branch (svn.gnome.org/svn/atk/branches/gnome-2-22). Now we will focus on TRUNK for the new features development. Thanks, l10n.gnome.org updated (at-spi is not concerned by i18n). Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: ATK, GAIL, AT-SPI branched for 2.22 (was: ATK branched for 2.22)
Le vendredi 14 mars 2008 à 23:05 +0100, Claude Paroz a écrit : Le vendredi 14 mars 2008 à 10:45 +0800, Li Yuan a écrit : Hi, ATK has been branched for GNOME 2.22 with the release of 1.22.0. ATK 1.22.0 sources represent the beginning of the branch (svn.gnome.org/svn/atk/branches/gnome-2-22). Now we will focus on TRUNK for the new features development. Thanks, l10n.gnome.org updated (at-spi is not concerned by i18n). Hmmm... at-spi *does* have string. Seems a missing module on l10n.gnome.org. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Improving things for translators
On Fri, 2008-03-14 at 22:53 +0100, Claude Paroz wrote: Le vendredi 14 mars 2008 à 16:12 -0500, Shaun McCance a écrit : Indeed. Documentation writing doesn't really heat up until after the feature freeze, which is roughly half way through our release cycle. That leaves the team three months to update all the documentation. Factor in these facts: 1) Our documentation is out of date, sometimes by as much as a few years. We're still trying to clear the backlog, so to speak, which makes for an even heavier workload. If we ever caught up, we'd be in a better position to make future updates in a timely manner. 2) The desktop release contains 86 documents. Some of them are smallish, but some of them are huge. We add new modules with every release. 3) We have almost no active writers at the moment. Virtually all updates are those that Ubuntu sends upstream. I'm way too busy being a hacker to be a writer. My long-standing policy on documentation freezes is that it's something we want to do at some point, but we're not in a position to do it right now. We need every last second we can get to do documentation. Hi Shaun, I'm convinced that a 3 day-freeze in a six months release won't change anything to the current lack of writers for docs. It's just a timing matter. As a translator, what I would absolutely prevent, it's what happened with the platform-overview document (excellent, by the way!) you updated some minutes/hours before releasing. We worked many hours on the translation of this document, Vincent and I, just to see it being only partially translated in GNOME 2.22 :-( If a freeze would have been in place, you probably would have planned to update the doc three days before. Don't take it as a personal attack, you had the right to do it that way. Honestly, I don't think I would have. I would have simply waited for the 2.22.1 release. I (co-)maintain four modules and I'm the de facto maintainer of 70+ individual documents. No amount of planning would make me able to finish everything on time. I'm very sorry that your hard work didn't result in a 100% translated document, and that there was really no way you could have fixed that. (That goes for Jorge as well; Spanish was also at 100% before my changes.) But I believe the changes had a net positive impact on the total readership. French and Spanish were the only two translations that would have been 100%, which means that a huge percentage of our readers will be reading in English. Having the information correct, in this case, was more important. What I would prefer to do, at least initially, is to implement voluntary freezes on documentation. Sorry, but a voluntary freeze means nothing to me. Either a normal freeze or nothing. I don't understand this. Frankly, I think voluntary freezes are a good idea, even if we have mandatory freezes as well. If we have a mandatory freeze three days before release, but I voluntarily freeze a week before, that's four extra days you can translate with a reasonable assurance that your work won't be wasted. We will never be able to have documentation freezes coincide with string freezes. Documentation provides orders of magnitude more total content to translate. It is virtually impossible for you to finish with a three day window. With Pulse (cue dramatic music) we could extract various bits of metadata about status, reviews, and readiness for translation from our documents. Then translators could look at Pulse to see which documents are worth devoting time to, and which are going to change out from underneath them. Whenever we finish a document (cue laughter), we'd mark it as such, and translators would know. Damned-lies already produces stats about new strings to translate. And we can assume that new strings committed in SVN means they are worth to be translated also. OK, it may also be work in progress, but in this special case, a simple mail to gnome-i18n will do the job. Like the documentation team, many translation teams are behind. They have a backlog, and they have to catch up. So say there was a paragraph added in 2.18. The Afrikaans team gets to the point where they're ready to translate documentation. It's not a new paragraph in 2.24, so it's not safe to assume, as in your example, that it's ready to be translated. Honestly, whether the translation teams want to look at documentation status or not, I will be adding it to Pulse. The documentation team needs to know where things stand in order to prioritize their efforts. It's in your best interest to prioritize documents that are marked final. Having fully translated documentation is of no use if what was translated was crap to begin with. Garbage in, garbage out. Of course, but we can say the same for programs. That doesn't prevent in any way to put a freeze in place for UI translations. I don't think that's comparable.
