Re: Translation status pages
Vincent Untz wrote: Le vendredi 07 octobre 2005 à 20:12 +0200, Danilo Šegan a écrit : Another disk optimisation is handling of cvs checkouts. For different reasons, all cvs checkouts are usually done in full, i.e. checkout is first removed, and only then is it cvs coed again. If there was no hand tuning of cvs repositories in Gnome, maybe cvs up -Pd would be sufficient? I don't know enough details of CVS hacking to answer this, but the basic thing is that we need to insure pristine CVS tree before running intltool-update -p and msgmerge. Also, is it really useful to checkout the whole modules? Wouldn't checking out only the po/ directories help? Vincent You can't extract strings from source files if you don't check out the source files themselves... # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: new GCompris release soon
Bruno Coudoin wrote: We are about to release a new GCompris release in a week, please update your translations. Every time I update my gcompris translation, I feel bad about using tons of bandwidth to d/l a bunch of ogg/image files. Would it be plausible and possible to have maybe a gcompris-data module that the larger data files (esp. sound files) could live in? [EMAIL PROTECTED]:~/build/po# gcvs co gcompris [EMAIL PROTECTED]:~/build/po# cd gcompris [EMAIL PROTECTED]:~/build/po/gcompris# du -h -d 0 . 71M. [EMAIL PROTECTED]:~/build/po/gcompris# find . -name \*.ogg -o -name \*.png -o -name \*.jpg | xargs rm [EMAIL PROTECTED]:~/build/po/gcompris# du -h -d 0 . 12M. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GConf reverse string freeze breakage approval
I jumped the gun and committed a string change without any approval whatsoever (except from the module maintainer). Danilo asked me to back out the change, and I'm perfectly willing to do so. But before I do, I wanted to see whether I can get the string change approved to remain in rather than backing it out. The change is outlined in Bug #301133. It does two things: it changes an instance of xml to XML, and changes configurion to configuration. The changes are small enough that they shouldn't mess up any translator efforts, and they're important enough that it'd be really good to have them in 2.12 rather than shipping with misspellings. I know that this is un-Kosher (and Danilo gave me a whipping; I've learned my lesson here), but I'd rather see these changes go into 2.12 than have to back them out. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
HEADS UP: gnome-build string changes
A spelling error was fixed in gnome-build to resolve bug #308027. It should only directly affect the English-based locales. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Should translators change source strings?
Clytie Siddall wrote:
On 08/08/2005, at 11:18 PM, Adam Weinberger wrote:
Every module may have a file named po/README.TRANSLATORS. In this
file, developers may put instructions such as Only simple spelling
and grammar fixes or Please make any change necessary or Do not
make changes at all or You break it, you buy it. Absence of po/
README.TRANSLATORS will mean that translators have implicit
permission to edit the source strings themselves to resolve simple,
obvious grammar and spelling errors. (I.e. more complex or non-
obvious changes will still require a bugzilla bug to be filed.)
This would save a lot of time, but how does it work with gettext? I
thought changing _anything_ in a source string would make the .mo file
fail on reintegration.
Not source string as in
# src/foo.c, 135
msgstr pants
I'm talking about editing a source string as in
vi src/foo.c +135
{
printf(_(pants));
}
# Adam
--
Adam Weinberger
[EMAIL PROTECTED] || [EMAIL PROTECTED]
[EMAIL PROTECTED]|| [EMAIL PROTECTED]
http://www.vectors.cx
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Error after commit?
Арангел Ангов wrote: I'm commiting an updated translation of gdm2 and I get this: Checking in mk.po; /cvs/gnome/gdm2/po/mk.po,v -- mk.po new revision: 1.17; previous revision: 1.16 done *Cannot open file /tmp/#cvs-po.lastdir.595. -- *What's all this about? :\ I've been getting that with every GNOME commit I've made in the last couple weeks. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Should translators change source strings?
[ I'm adding d-d-l to the Cc: list here, folks. If it doesn't make it through to that list, please forward a copy to it. ] Clytie Siddall wrote: On 08/08/2005, at 3:35 PM, Adam Weinberger wrote: One of them says password is to simple. This is also a current error in gdm2. I was about to report is as a bug. Should I still do that? If a string has a major grammar or spelling error like that, then it should definitely have a bug filed against it. Done. I seem to spend half my time in Bugzilla at Gnome. :( It's not too bad when I update the files, but the first pass ... LOTS of errors. Is it possible to run an English spellchecker over the .po files? Trust me: you don't want to do that. There are literally hundreds of strings with grammar or spelling errors, terrible word choices, made-up words, or simply lazy strings. The simple truth is that developers spend their time concentrating on code, not on strings. (And with good reason!) GNOME simply will never be taken seriously until the quality of the strings improves. Programs like Evolution should be a blessing to companies that want a respectable mailer. But I personally am embarrassed to think about suggesting that a self-respecting company should switch to something with strings like Click here, you can find more events. or You will not be able to either send or recieve mails now. (Apologies, Evolution, for picking on you here. Your strings are in no way the worst, but your app is one of the best.) The problem with fixing these by filing bugreports is that it wastes an incredible amount of translator and developer time. Furthermore, they're ignored more often than not, or argued with. I can't recall how many occured-related reports I've filed; I once had someone argue that can not was a perfectly reasonable spelling of cannot; there are so many comma-spliced strings in CVS right now that it would take down bugzilla if I were to file bugreports against them all. See, we have a team of brilliant developers, writing brilliant code, which is what they're good at. We have a team of dedicated and hard-working translators who focus on their language, but ignore the source strings. And why? Each source string is looked at by easily 50 pairs of translator eyes, and by only 1 developer's eyes (and his or her eyes are for the code, not the string). We are under-utilizing our translators' abilities. For every developer that doesn't wish to spend his or her time making grammar and spelling changes, I propose the following: Every module may have a file named po/README.TRANSLATORS. In this file, developers may put instructions such as Only simple spelling and grammar fixes or Please make any change necessary or Do not make changes at all or You break it, you buy it. Absence of po/README.TRANSLATORS will mean that translators have implicit permission to edit the source strings themselves to resolve simple, obvious grammar and spelling errors. (I.e. more complex or non-obvious changes will still require a bugzilla bug to be filed.) I think that GNOME would stand to benefit significantly from this. Having translators fixing grammar and spelling problems on their own, rather than just patching them over in their translation, could only benefit the project. Nothing takes down the appearance of maturity and elegance of a program like seeing a glaring An error is occured dialogue box jumping out at you. Developers: what say you? Do you like this idea? # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Should translators change source strings?
Mark McLoughlin wrote: On Mon, 2005-08-08 at 09:48 -0400, Adam Weinberger wrote: Absence of po/README.TRANSLATORS will mean that translators have implicit permission to edit the source strings themselves to resolve simple, obvious grammar and spelling errors. I think this is mostly fair enough, but I wouldn't like to see a situation where translators routinely re-phrase messages or chose different terminology. Heh, I don't think anybody else would want that either. I'm talking about typos and brainos. Although I'd like to hope that modules maintained by non-English-speakers would put something in README.TRANSLATORS that says something to the effect of feel free to edit strings into what I intended for them. e.g. I could imagine a situation where a translator goes on a crusade through nautilus replacing the word directory everywhere with the word folder where, in fact, there might have been a long discussion in the past about which term is most appropriate in that context. I think the proper phrase here would be obvious fixes only. So, I think it makes sense that the maintainer should be involved (through bugzilla) with string changes, even just as an arbitrator, unless its a very obvious typo of some sort. And even with obvious typos, sending the maintainer the patch with a mail I've just committed this obvious fix is always polite. Developers have the right to say don't touch my code! but I'd hope that most people wouldn't. The more bureaucracy there is in changing strings, the fewer the number of strings that will be changed. Too few controls, and we'd have xadAmxR0xx0rzx!!!1 prepended to every dialogue message. I think there's an acceptable balance that we can hit. Also, I'd hope that translators would be well aware of when string freezes are in effect :-) It's like rain. On your wedding day. ::-P # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Evolution addressbook string change
Arunprakash wrote: Hi, The patch for bug #310343 adds the following two strings. N_(Not available in offline) N_(Invalid server version) The word offline is an adjective, but you're using it here as a noun. That's very confusing. Not available in offline mode would make a lot more sense to me. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: is there any use to keep translating gnome 2.10?
Danilo egan wrote: Hi Yair, As long as there are chances that maintainers will roll out tarballs of their apps along with updated translations from gnome-2-10 branches, YES! And those chances are pretty good, no matter if there's not any other 2.10.* release scheduled on [1], and it's so for at least another month or so (unless you really believe Gnome 2.10.1 release to be completely bug-free :). [1] http://live.gnome.org/ReleasePlanning_2fTwoPointEleven You know, it'd be really nice for app maintainers to let us know when they're not going to release any new versions from a branch. There are many apps and libs that are released once per GNOME release, and never again. Yet people are still asked to translate their gnome-2-10 branches. IMO maintainers should really be putting a note at the top of a ChangeLog when they're not planning on making any new releases from a particular branch. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Wasted resources
Clytie Siddall wrote: On 18/05/2005, at 2:40 AM, Jaap Haitsma wrote: Pootle sounds very interesting, especially the fact that it can handle multiple file types. (po, mozilla, openoffice etc.) Yes, it's very adaptable. I've just translated a manpage on Pootle. :) Now it would be nice if there was going to be just one central place on the web where the translations would take place. Now there will be a lot of duplicated effort of translators. (people using pootle, rosetta, cvs/svn ). There could be an official GNOME web based translation site, but I think it would be even better if translator of a certain locale would all work together. This is especially true for small languages. I agree wholeheartedly, Jaap! The thing I've noticed most since stumbling into the i18n arena, and which frustrates me the most, is how fragmented it is. You meet the same hard-working translators and co-ordinators everywhere, doing the same job over and over in ways which vary for no apparent reason, but because they belong to that project. With so few resources (especially, as you note, for languages with few translators: we have three, worldwide), it's so wasteful and inefficient to duplicate like this, and spend so much time learning to use the local procedures. OSS _should_ be about sharing our resources and working together. When will this happen in i18n? from Clytie (vi-VN, team/nhm Gnome-vi) Clytie Siddall--Renmark, in the Riverland of South Australia Sharing resources and working together does not equate to everybody on my team should use this tool that I like. There are some of us who prefer CVS and abhor the thought of using a GUI or web-based translation tool. I personally do all my work from a terminal, and a web-based or GUI tool would not fit any of my needs. But the point is that my reasons for wanting to use a terminal are exactly the same as your reasons for preferring pootle, and others' reasons for preferring rosetta or gtranslator or etc.: it's the environment which best suits your needs. You're barking up the wrong tree here. Don't focus your energy on finding one way of doing things that you feel everybody should follow. If you are a huge fan of pootle, join the pootle project. Contribute code, thoughts, ideas, and advocacy. But please, recognize how easily people get into application-based Holy Wars. Though your intentions are good, implying that people should use a method that obviates their own may well lead to more problems than it solves. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation re-start
James R. Johnson wrote: Hello, I was wondering, where do I go to get the Gnome 2.10 files so I can begin translating again into Old English? http://l10n-status.gnome.org/gnome-2.10/ang/index.html Are you sure you want to translate GNOME 2.10 instead of GNOME 2.12? # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: still can't commit
Clytie Siddall wrote: Hi again :) I still can't get most files to update when committed. For example, this page: http://l10n-status.gnome.org/gnome-2.10/vi/desktop/index.html shows the file file-roller as incomplete: 190 complete strings, 51 fuzzy and 29 empty. I completed this file some time ago, and keep trying to submit it. Today, I tried checking it out to another directory, as advised by my team leader: Pearl:~/gnome clytie$ cvs -z3 -d :ext:[EMAIL PROTECTED]:/cvs/gnome co -r gnome-2-10 file-roller/po cvs server: Updating file-roller/po snip U file-roller/po/uk.po U file-roller/po/vi.po U file-roller/po/xh.po U file-roller/po/zh_CN.po U file-roller/po/zh_TW.po Then I compared the file from cvs and my file on my hard disk: they were identical. Absolutely _no_ fuzzy or incomplete strings. However, I kept trying: Pearl:~/gnome clytie$ cd file-roller/po Pearl:~/gnome/file-roller/po clytie$ vi ChangeLog Pearl:~/gnome/file-roller/po clytie$ cvs commit cvs commit: Examining . Checking in ChangeLog; /cvs/gnome/file-roller/po/ChangeLog,v -- ChangeLog new revision: 1.601.2.6; previous revision: 1.601.2.5 done Pearl:~/gnome/file-roller/po clytie$ and it updated nothing. Please, what am I doing wrong? Christian ran intltool-update vi over the files that wouldn't commit, on the 29th May, and, still using this example file: file-rollerHEAD179 / 52 / 28Clytie Siddall gnome-2-10229 / 34 / 7Trinh Minh Thanh I don't submit incomplete files, I would get too confused. I submitted that dratted file in msgfmt-perfect form ages ago, but it just won't update. Any help you can offer would be very gratefully received. I am starting to feel very discouraged. :(( from Clytie (vi-VN, team/nhm Gnome-vi) Clytie Siddall--Renmark, in the Riverland of South Australia thnh ph Renmark, ti min sng ca Nam c First of all, the file-roller behaviour you're experiencing with regards to the status page may be due to the fact that ar.po was committed with errors (let this be a reminder to everybody to ALWAYS run msgfmt *BEFORE* committing). The status pages generator may be choking on ar.po and not generating updated stats. (p.s. maintainer of ar.po, please fix your broken translation file!) As far as making commits goes, I can commit to vi.po just fine. If you want to see this for yourself, try: $ cvs co file-roller $ cd file-roller/po $ intltool-update vi.po $ cvs commit That should update the timestamp within vi.po, and cvs(1) should recognize the diff. Your translation file *is* up-to-date, with no fuzzy/untranslated strings. What the log above does not show is you making any changes to vi.po itself, so running cvs commit wouldn't offer to commit anything to it. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: l10n-status website suggestions
Abel Cheung wrote: On 5/5/05, Adam Weinberger [EMAIL PROTECTED] wrote: Right now, the main translation handler is written in C, and is thus very difficult to modify. Just curious, it sounds like you want to use scripting language? (everybody please no language war here) There are languages better able to handle string manipulation and website generation than C. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: erratic commit records?
Clytie Siddall wrote:
Hi everyone :)
I started asking the cvs people, but it seems to be something I'm doing
wrong. I wish I could work out what. :(
Christian Rose got me the following data. I have translated or
completed the translations on all the files on this page...:
http://l10n-status.gnome.org/gnome-2.10/vi/desktop/index.html
down to and including gnome-applets. I have checked them manually,
string by string, and run them through msgfmt. Once I was satisfied
there were _no_ missing, incomplete or fuzzy strings, I committed them.
Yet the data shows several files unchanged. Some commit OK, some don't.
modulebranchstatus (translated / fuzzy /
untranslated)
===
===
dashergnome-2-1099 / 0 / 34
evolution-exchangegnome-2-10322 / 2/ 0
file-rollergnome-2-10229 / 34 / 7
galgnome-2-10236 / 5 / 9
gconf-editorHEAD72 / 25 / 1
gdm2gnome-2-10684 / 22 / 2
ggvHEAD257 / 12 / 5
gnome-appletsgnome-2-10698 / 130 / 124
I've checked the actual status for these modules as well, both in their
HEAD branch and in their gnome-2-10 branch if such existed, by checking
out the modules myself and running 'intltool-update vi' to check the
current status:
modulebranchstatuslast translator
===
===
dasherHEAD133 / 2 / 3Clytie Siddall
gnome-2-1099 / 0 / 34pclouds
---
---
evolution-exchangeHEAD319 / 2 / 3Phan Vinh Thinh
gnome-2-10322 / 2 / 0Clytie Siddall
---
---
file-rollerHEAD179 / 52 / 28Clytie Siddall
gnome-2-10229 / 34 / 7Trinh Minh Thanh
---
---
galHEAD186 / 29 / 35Trinh Minh Thanh
gnome-2-10236 / 5 / 9Clytie Siddall
---
---
gconf-editorHEAD72 / 25 / 1Clytie Siddall
---
---
gdm2HEAD595 / 117 / 26pclouds
gnome-2-10684 / 22 / 2Clytie Siddall
---
---
ggvHEAD257 / 12 / 5Clytie Siddall
---
---
gnome-appletsHEAD649 / 136 / 183pclouds
gnome-2-10698 / 130 / 124Clytie Siddall
---
---
All those files with my name are complete. Where on earth are they??
Thus, I couldn't find any erratic entries on the status pages; they all
appear to be correct.
The problems could be caused by any number of reasons: You could simply
be committing to another branch than the one you intended, you could be
using a po file from a gnome-2-10 branch and be committing it to HEAD
and vice versa, and so on.
Please tell me if I'm doing the right thing: I am following the
instructions on the page about using Gnome cvs as a translator.
1. I checkout the .po directory of the file I'm translating or editing.
(a) if a HEAD file:
cvs -z3 -d :ext:[EMAIL PROTECTED]:/cvs/gnome co FILENAME/po
(b) if a gnome-2-10 file:
cvs -z3 -d :ext:[EMAIL PROTECTED]:/cvs/gnome -r gnome-2-10 FILENAME/po
2. I even change the name of the directory on my drive, once I've
checked it out, to gnome-2-10-FILENAME if it's a gnome-2-10 branch file.
3. Once I've finished the file, I change to the gnome/HEAD/FILENAME/po
or gnome/gnome-2-10/gnome-2-10-FILENAME/po directory and run:
cvs -z3 -d :ext:[EMAIL PROTECTED]:/cvs/gnome up -Pd
4. Then I edit the ChangeLog.
5. Then I run:
cvs commit
which says it's committed the changes.
Please tell me what I'm doing wrong. It's really frustrating to have
done all that work, and not see it update at all.
:(
Thankyou for any help you can offer.
Your problem is Step 3. By running cvs up, you overwrite the po file
you've just edited. Try the following steps instead:
1. cvs co {-r gnome-2-10} module/po
2. cd module/po
3. edit your_translation.po, ChangeLog
4. cvs commit
# Adam
--
Adam Weinberger
[EMAIL PROTECTED] || [EMAIL PROTECTED]
[EMAIL PROTECTED]|| [EMAIL PROTECTED]
http://www.vectors.cx
___
gnome-i18n mailing list
gnome
Gossip should now be translated from HEAD
I figured that this branch change would probably warrant a quick note to you all, just in case there is any confusion. Gossip has, until now, been generating GTP status page stats from the gossip-0.8 branch. After discussions with the author, I've switched it over to HEAD (the default branch). This means that your stats for gossip might drop to 0, even if you previously had 100% complete translations for gossip. You can fix this by copying your translation file from the gossip-0.8 branch over to the HEAD branch. That does qualify as a potentially tricky CVS manoeuvre, so if anybody would like me to handle that for their translation, please just shoot me an email and let me know. Thanks, and sorry in advance for any confusion this causes. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: libgnomeui has been branched
Tor Lillqvist wrote: A gnome-2-10 branch has been created for libgnomeui. The HEAD branch will get Win32 portability changes applied. I am bumping the version in HEAD to 2.11.0. --tml Thanks for the notice! The GTP status pages will reflect this new branch when they next update. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: blank on po stat page
On Mon, 2005-28-03 at 08:41 +0700, ahmad riza h nst wrote: hi... when i browse http://l10n-status.gnome.org/gnome-2.12/id/desktop/index.html i got blank page... :D is it somethink wrong or me ?? It's not just you. Something has gone wrong on the backend for generation of individual status pages. There's been no word yet on whether it was a one-time hiccough, or whether something was misconfigured. People are looking into it, though. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: eel/nautilus branched for 2.10
On Tue, 2005-22-03 at 10:47 +0100, Alexander Larsson wrote: The new branch for 2.10 work for eel and nautilus is gnome-2-10. HEAD will start with 2.11 work. The status files have been updated. The status pages should reflect the new branches at the next update. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Time for gnome 2.12 stats?
Danilo egan wrote: Hi Martin, Today at 15:29, Martin Willemoes Hansen wrote: Everything is supposed to be done only when someone gets around to actually doing it :) So far, I didn't see anyone step up (hint, hint :-P) Howto do it? One would need to update gnome-i18n/status/data/translation-status.xml file accordingly. This would be tedious, so I've written a Python script to do it (I'm attaching it here, I'll also commit it to gnome-i18n/status/data/new-release), but I didn't test it extensively. Christian Rose used to do this, and we should probably wait for his approval before doing anything of this kind. Now, I'd appreciate your help in checking that this doesn't break anything (i.e. do the following: $ ./new-release | xmllint --format - new.xml $ diff -u translation-status.xml new.xml and only if everything looks fine in the diff $ cp new.xml translation-status.xml edit ChangeLog, and finally $ cvs ci ). It's not easy this first time, since there are indentation changes, but it should be easier in the future if we keep it xmllint --format-indented. The outputted file looks good to me and the changes make sense. I'm going to beg publically once more for the website sources to PLEASE PLEASE be released publically. If they were, I could test the changes locally. In any event, your script has my vote of confidence. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Very odd translation behaviour
Vincent Untz wrote: Hi Adam Le jeudi 17 mars 2005 10:09 -0500, Adam Weinberger a crit : Can somebody please help me investigate? On my FreeBSD 5-STABLE box running GNOME 2.10 with LANG=en_CA.ISO8859-1, I get the following by default with gnome-backgrounds-2.10.0 installed when I run the background selector app. Note that the strings in the selector app are in the proper en_CA locale (such as the 'u' in Desktop Colours) but the named of the background images are in, uh... I'm not sure. http://people.freebsd.org/~adamw/gg-background.png Does anybody else see this on their system if they try the en_CA locale? This could be http://bugzilla.gnome.org/show_bug.cgi?id=168907 Try to remove ~/.gnome2/backgrounds.xml and everything should be okay :-) Right you are, sir! Thank you! # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: typo in gedit string
Paolo Borelli wrote: Christian spotted this typo in gedit: #: plugins/taglist/HTML.tags.xml.in.h:29 msgid Char enconding of linked resource (note encoNding) which should be changed to Character encoding of linked resource is it ok break the string freeze for this? This change looks correct to me. # Adam -- Adam Weinberger [EMAIL PROTECTED] || [EMAIL PROTECTED] [EMAIL PROTECTED]|| [EMAIL PROTECTED] http://www.vectors.cx ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
