Using Git and separating translations into their own l10n-LL repository
Hi All,
This is a long-ish post regarding the migration to Git and
what we can do to make l10n a bit better.
Here I suggest to use the 'git submodule' support
so that the translation material for each language
reside in a single repository.
Comments would be appreciated.
If all is fine, I'll put this, with more details, to live.gnome.org.
When splitting the l10n files from each module, there is a choice to either
1. create a companion repository for each module (for example, for
mousetweaks, create 'mousetweaks-l10n')
that will hold all localisation files for all languages, for this module.
If we have 1000 modules, there would be 1000 additional companion l10n modules.
2. create a repository for each language, and this repository will
contain all localisation files for all modules.
If we have 1000 modules, there would be just 160 additional l10n
repositories (it's one new repository per language).
The right choice appears to be to create one repository per language.
There are many reasons which can be discussed if deemed necessary.
The rest of the e-mail shows how the separated repositories look like.
I used as an example the mousetweaks and vinagre modules, for the el,
es, fr and sv languages.
Both have help/ and po/ subdirectories with l10n material.
You can fork the generated (six) repositories from
http://github.com/simos/ if you want to try them out.
STRUCTURE (l10n-LL)
A language repository name is of the form 'l10n-LL', where LL is the
ISO 639 (-123) language code as usual.
Inside 'l10n-LL' there are directories per module (with the module
name), and further subdirectories 'po/' and 'help/' as necessary.
For example,
l10n-el
├─ mousetweaks
│ ├─ help
│ │ └─ el
│ │ └─ el.po
│ └─ po
│ └─ el.po
└─ vinagre
├─ help
│ └─ el
│ └─ el.po
└─ po
└─ el.po
and
l10n-es
├─ mousetweaks
│ ├─ help
│ │ └─ es
│ │ ├─ es.po
│ │ └─ figures
│ │ ├─ mouse-a11y-add-applet-to-panel-window.png
│ │ ├─ mouse-a11y-dwell-checkbox.png
│ │ ├─ mouse-a11y-dwell-click-type-applet.png
│ │ ├─ mouse-a11y-dwell-click-type-window.png
│ │ ├─ mouse-a11y-dwell-ctw-checkbox.png
│ │ ├─ mouse-a11y-dwell-delay-slider.png
│ │ ├─ mouse-a11y-dwell-gesture-mapping.png
│ │ ├─ mouse-a11y-dwell-mode-choice.png
│ │ ├─ mouse-a11y-dwell-motion-treshold.png
│ │ ├─ mouse-a11y-pointer-capture-context-menu.png
│ │ ├─ mouse-a11y-pointer-capture-locked.png
│ │ ├─ mouse-a11y-pointer-capture-preferences.png
│ │ ├─ mouse-a11y-ssc-checkbox.png
│ │ ├─ mouse-a11y-ssc-delay-slider.png
│ │ └─ mouse-a11y-tab.png
│ └─ po
│ └─ es.po
└─ vinagre
├─ help
│ └─ es
│ ├─ es.po
│ └─ figures
│ └─ vinagre-screenshot.png
└─ po
└─ es.po
STRUCTURE ('l10n' supermodule)
Per git parlance, we create a 'l10n' supermodule, and inside it we add
each language repository as submodules.
Thus,
l10n
├─ README
├─ l10n-el/
├─ l10n-es/
├─ l10n-fr/
└─ l10n-sv/
The above graphic shows the first level of directories.
When we add a new language, the l10n coordinators will add a new entry
here to the new repository 'l10n-LL'.
Each 'l10n-LL' entry is added with 'git submodule add', and points to
a repository created earlier.
STRUCTURE (module)
Now, each module (such as mousetweaks and vinagre) need to simply add
the 'l10n' supermodule.
We remove from help/ and po/ all *.po and figures/ files. For our two
modules, the po/ and help/ subdirectories would look like
mousetweak:
po
├─ LINGUAS
├─ POTFILES.in
└─ POTFILES.skip
help
├─ C
│ ├─ figures
│ │ ├─ mouse-a11y-dwell-checkbox.png
│ │ ├─ mouse-a11y-dwell-click-type-applet.png
│ │ ├─ mouse-a11y-dwell-click-type-window.png
│ │ ├─ mouse-a11y-dwell-ctw-checkbox.png
│ │ ├─ mouse-a11y-dwell-delay-slider.png
│ │ ├─ mouse-a11y-dwell-gesture-mapping.png
│ │ ├─ mouse-a11y-dwell-mode-choice.png
│ │ ├─ mouse-a11y-dwell-motion-treshold.png
│ │ ├─ mouse-a11y-pointer-capture-context-menu.png
│ │ ├─ mouse-a11y-pointer-capture-locked.png
│ │ ├─ mouse-a11y-pointer-capture-preferences.png
│ │ ├─ mouse-a11y-ssc-checkbox.png
│ │ ├─ mouse-a11y-ssc-delay-slider.png
│ │ └─ mouse-a11y-tab.png
│ ├─ legal.xml
│ └─ mousetweaks.xml
├─ Makefile.am
└─ mousetweaks.omf.in
vinagre:
po
├─ LINGUAS
├─ POTFILES.in
└─ POTFILES.skip
help
├─ C
│ ├─ figures
│ │ └─ vinagre-screenshot.png
│ ├─ legal.xml
│ └─ vinagre.xml
├─ Makefile.am
└─ vinagre.omf.in
(mental hint: the C/ folder should actually move to the 'l10n'
supermodule, in 'l10n-C')
We have removed the ChangeLog files as the commits are moved to the submodules.
We have to figure out what to do LINGU
Re: Using Git and separating translations into their own l10n-LL repository
On Tue, Jan 13, 2009 at 11:31 PM, Gil Forcada wrote: > Hi Simos, > > Great explanation, a couple of questions: > > - There would be any way to have in a single folder the code and > translations (aka, the way is right now)? There are some translators > (I'm counting in) that likes to have the code also. I am not sure which module you have in mind. I would say that the idea is, if the translation files are expected to be managed by damned-lies/l10n.gnome.org, they should reside in the l10n-LL submodule. > - The same concern about maintainers forgetting to git pull(?) > translators is expanded, now they should git pull(?) every single git > repository (if 160 languages, 160 git pulls(?) before each release). The 'git submodule update' command, when you run in from the 'l10n' supermodule, pulls all the l10n-LL repositories automatically by default. There is an option to 'git submodule update' to pull individual language repositories as well. > Also, if the new DL will have commit functionality (maybe in half a > year, Claude ... :) and then *all* translations will be committed this > way, wouldn't be overkill to have all this system? > > I mean, if it's a temporal situation that, shouldn't be more productive > to instead of "wasting" time doing this git submodule thing to provide > resources and time to get commit functionality to DL that seems to be > more desired by translators (that's my guess no data actually, just > supposed so my arguments seems better :D). I would consider that separating code from localisation files would be a fundamental improvement rather than a temporary solution. The issue of manpower to make such changes is the main disadvantage. It would be easier to provide commit support to damned-lies when we have separated l10n-LL repositories. Damned-lies would 'auto'-commit only to designated repositories. I do not know the details of the SVN hooks and damned-lies. I think that if a commit/push to a project would call a hook that would invoke 'intltool-update -P' (create POT template file) and store it somewhere, then damned-lies would not need to clone locally any other GNOME modules. To add a few more advantages, 1. Can add access controls for translators to the l10n-LL repositories. 2. It allows translators to make changes across all translations (for example, change 'widget' in all my translations of GNOME). 3. Pootle could be adapted to perform easier GNOME translation marathons. 4. GTranslator could work as KBabel, it would clone the l10n-LL repository and would be able to show all translations in a huge sorted list. This way, similar translations can be easily identified. > > El dt 13 de 01 de 2009 a les 23:01 +, en/na Simos Xenitellis va > escriure: >> Hi All, >> >> This is a long-ish post regarding the migration to Git and >> what we can do to make l10n a bit better. >> >> Here I suggest to use the 'git submodule' support >> so that the translation material for each language >> reside in a single repository. >> Comments would be appreciated. >> If all is fine, I'll put this, with more details, to live.gnome.org. >> >> When splitting the l10n files from each module, there is a choice to either >> 1. create a companion repository for each module (for example, for >> mousetweaks, create 'mousetweaks-l10n') >> that will hold all localisation files for all languages, for this module. >> If we have 1000 modules, there would be 1000 additional companion l10n >> modules. >> 2. create a repository for each language, and this repository will >> contain all localisation files for all modules. >> If we have 1000 modules, there would be just 160 additional l10n >> repositories (it's one new repository per language). >> >> The right choice appears to be to create one repository per language. >> There are many reasons which can be discussed if deemed necessary. >> >> The rest of the e-mail shows how the separated repositories look like. >> I used as an example the mousetweaks and vinagre modules, for the el, >> es, fr and sv languages. >> Both have help/ and po/ subdirectories with l10n material. >> You can fork the generated (six) repositories from >> http://github.com/simos/ if you want to try them out. >> >> STRUCTURE (l10n-LL) >> A language repository name is of the form 'l10n-LL', where LL is the >> ISO 639 (-123) language code as usual. >> Inside 'l10n-LL' there are directories per module (with the module >> name), and further subdirectories 'po/' and 'help/' as necessary. >> For example, >> >> l10n-el >&g
Re: Using Git and separating translations into their own l10n-LL repository
On Wed, Jan 14, 2009 at 3:34 PM, Gil Forcada wrote: > El dc 14 de 01 de 2009 a les 00:42 +, en/na Simos Xenitellis va > escriure: >> On Tue, Jan 13, 2009 at 11:31 PM, Gil Forcada wrote: >> > Hi Simos, >> > >> > Great explanation, a couple of questions: >> > >> > - There would be any way to have in a single folder the code and >> > translations (aka, the way is right now)? There are some translators >> > (I'm counting in) that likes to have the code also. >> >> I am not sure which module you have in mind. > > Sorry, I wasn't really clear. I meant to keep like it is now with code > and translations together. > >> I would say that the idea is, if the translation files are expected to >> be managed by damned-lies/l10n.gnome.org, they should reside in the >> l10n-LL submodule. >> >> > - The same concern about maintainers forgetting to git pull(?) >> > translators is expanded, now they should git pull(?) every single git >> > repository (if 160 languages, 160 git pulls(?) before each release). >> >> The 'git submodule update' command, when you run in from the 'l10n' >> supermodule, >> pulls all the l10n-LL repositories automatically by default. >> There is an option to 'git submodule update' to pull individual >> language repositories as well. > > If I understand correctly the repository will be like: > l10n > - l10n-LL > -- evolution > --- po > LL.po > -- eog > --- po > LL.po > ... > > So if they update the whole l10n module (the top module) they will get > all translations from all modules not all translations from their > module. Indeed, that is an issue. I did not find an easy way so that the 'l10n' tree can stay outside the repositories, and each module would have a symbolic link towards 'l10n'. That is, mousetweaks ├─ l10n (link to ../l10n) │... In addition to this, there is the issue with branching; all modules in a GNOME release should branch at the same time, and have a standard common branch name. Cheers, Simos > >> > Also, if the new DL will have commit functionality (maybe in half a >> > year, Claude ... :) and then *all* translations will be committed this >> > way, wouldn't be overkill to have all this system? >> > >> > I mean, if it's a temporal situation that, shouldn't be more productive >> > to instead of "wasting" time doing this git submodule thing to provide >> > resources and time to get commit functionality to DL that seems to be >> > more desired by translators (that's my guess no data actually, just >> > supposed so my arguments seems better :D). >> >> I would consider that separating code from localisation files would be >> a fundamental improvement rather than a temporary solution. >> The issue of manpower to make such changes is the main disadvantage. >> >> It would be easier to provide commit support to damned-lies when >> we have separated l10n-LL repositories. Damned-lies would 'auto'-commit >> only to designated repositories. >> >> I do not know the details of the SVN hooks and damned-lies. I think >> that if a commit/push to a project would call a hook that would invoke >> 'intltool-update -P' (create POT template file) and store it >> somewhere, then damned-lies would not need to clone locally any other >> GNOME modules. >> >> To add a few more advantages, >> 1. Can add access controls for translators to the l10n-LL repositories. >> 2. It allows translators to make changes across all translations (for >> example, change 'widget' in all my translations of GNOME). >> 3. Pootle could be adapted to perform easier GNOME translation marathons. >> 4. GTranslator could work as KBabel, it would clone the l10n-LL >> repository and would be able to show all translations in a huge sorted >> list. This way, similar translations can be easily identified. >> >> > >> > El dt 13 de 01 de 2009 a les 23:01 +, en/na Simos Xenitellis va >> > escriure: >> >> Hi All, >> >> >> >> This is a long-ish post regarding the migration to Git and >> >> what we can do to make l10n a bit better. >> >> >> >> Here I suggest to use the 'git submodule' support >> >> so that the translation material for each language >> >> reside in a single repository. >> >> Comments would be appreciated. >> >> If all is fine, I'll put this, with more details, to live.gnome.o
Re: Using Git and separating translations into their own l10n-LL repository
On Sat, Jan 17, 2009 at 6:39 PM, Kenneth Nielsen wrote: > 2009/1/16 Gil Forcada : >> >> El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va >> escriure: >>> On 1/15/09, Claude Paroz wrote: >>> > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit : >>> > > This is a long-ish post regarding the migration to Git and >>> > > what we can do to make l10n a bit better. >>> > > >>> > > Here I suggest to use the 'git submodule' support >>> > > so that the translation material for each language >>> > > reside in a single repository. >>> > > Comments would be appreciated. >>> > > If all is fine, I'll put this, with more details, to live.gnome.org. >>> > >>> > >>> > >>> > Thanks Simos for taking the time to evaluate such an infrastructure for >>> > l10n. >>> > However I doubt the relative complexity implied by your solution is >>> > worth the trouble. I see basically two use cases: >>> > >>> > 1. The non-technical coordinator, who would like the simplest >>> > infrastructure to commit his translation files. >>> > >>> > -> In this case, an auto-commit feature integrated in damned-lies is the >>> > best solution. No (D)VCS knowledge is required for him. FYI I've already >>> > tested a prototype which can do this in the testbed git infrastructure. >>> > >>> > >>> > 2. The geek coordinator who like to have the most control on what he's >>> > doing and how he do it. >>> > >>> > -> IMHO, this one won't mind checking out entire git modules. This is >>> > not very much different than the current situation. >>> >>> FWIW, I fully agree with Claude here. >> >> +1 also :) > > And a +1 from me. OK, let's summarize for future reference and close the thread. One of the issues to try to split translation files from the rest of the modules is because a 'git clone' downloads the full history of a repository, compared to a 'svn checkout' which downloads just a snapshot. In addition, svn can also checkout a subdirectory of a repository, something that git cannot do. Separating the repositories in code and translations using 'git submodule' would add too much effort in terms of updating the tools, and changing the practices that translators would use to maintain the translations. It is easier to keep as is. In terms of disk space, a 'git clone' is surprisingly very economic, almost matching an 'svn checkout'. In terms of speed when cloning a repository, git is more CPU intensive for the GIT server, and is slower than a 'svn checkout'. It would make sense for translators to dedicate some space so that cloned repositories are kept locally (instead of erasing them). Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
On Sun, Jan 18, 2009 at 9:55 AM, Gil Forcada wrote: > There isn't an option (I have read it somewhere, sorry for bad > references) that tells git to only download the last version and not the > full history? There is an option '--depth 1' that you can use when you clone a repository. Depending on the module, I noticed it gives up to moderate time and space improvements. git.gnome.org is now down, so I tried with git://anongit.freedesktop.org/git/xorg/xserver Clone: 1.43 min, objects 26.19 MiB, directory size 55MB Shallow clone: 50s, objects 16.22 MiB, directory size 43MB I also tried with the Linux kernel, git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Clone: 9.10min, objects 258.23 MiB, directory size 660MB Shallow clone: 5.38min, objects 152.34 MiB, directory size 531MB When cloning, the 'Receiving objects' stage is the one that takes most of the time and refers to compressed data. I suppose it is a good indication of the total time. When I tried the other day with git.gnome.org, I noticed much slower times. It appears the reason is that git.gnome.org (test server) was very slow when I tried it, achieving up to 100KB/s at best. With X.Org and the Linux kernel, the speed was most of the time at 800KB/s. In addition, the 'git clone' man page mentions "--depth Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches." It says that you cannot "push from [a shallow clone]", which means that a translator would not be able to push a translation from a shallow clone. I tried with a small repository where I have push access and I was able to push a commit from a shallow clone to the git server. This may be some feature on GitHub; all Google searches for 'shallow clone' repeat that you cannot push your changes from your shallow clone. It would be important to try this one out on git.gnome.org, when it is available. Simos > Cheers, > > El dg 18 de 01 de 2009 a les 00:01 +, en/na Simos Xenitellis va > escriure: >> On Sat, Jan 17, 2009 at 6:39 PM, Kenneth Nielsen >> wrote: >> > 2009/1/16 Gil Forcada : >> >> >> >> El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va >> >> escriure: >> >>> On 1/15/09, Claude Paroz wrote: >> >>> > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit : >> >>> > > This is a long-ish post regarding the migration to Git and >> >>> > > what we can do to make l10n a bit better. >> >>> > > >> >>> > > Here I suggest to use the 'git submodule' support >> >>> > > so that the translation material for each language >> >>> > > reside in a single repository. >> >>> > > Comments would be appreciated. >> >>> > > If all is fine, I'll put this, with more details, to live.gnome.org. >> >>> > >> >>> > >> >>> > >> >>> > Thanks Simos for taking the time to evaluate such an infrastructure >> >>> > for >> >>> > l10n. >> >>> > However I doubt the relative complexity implied by your solution is >> >>> > worth the trouble. I see basically two use cases: >> >>> > >> >>> > 1. The non-technical coordinator, who would like the simplest >> >>> > infrastructure to commit his translation files. >> >>> > >> >>> > -> In this case, an auto-commit feature integrated in damned-lies is >> >>> > the >> >>> > best solution. No (D)VCS knowledge is required for him. FYI I've >> >>> > already >> >>> > tested a prototype which can do this in the testbed git >> >>> > infrastructure. >> >>> > >> >>> > >> >>> > 2. The geek coordinator who like to have the most control on what he's >> >>> > doing and how he do it. >> >>> > >> >>> > -> IMHO, this one won't mind checking out entire git modules. This is >> >>> > not very much different than the current situation. >> >>> >> >>> FWIW, I fully agree with Claude here. >> >> >> >> +1 also :) >> > >> > And a +1 from me. >&g
Re: Using Git and separating translations into their own l10n-LL repository
On Mon, Jan 19, 2009 at 12:57 PM, Matej Urban wrote: > Thanks, Gil, > > I will wait and see, but since I'm a translator/mantainer and since I > doubt I will be able to upload many files at once, the only difference > so far I see, is that I will replace keyboard keystrokes for mouse > clicks. There will be no changelog, which is an improvement :) > > Anyhow, in the end I will use whatever I'll need to do it, but keep > nagging about it. For some reason, I really doubt that single dir for > all po files, is a big programing deal. No obsolete clicks, no hassle, > just pure translation work. For the part where you would want to upload several PO files in one go, it should be feasible to adapt damned-lies (as soon as single PO file uploads are enabled) to upload .tar.gz archives of several PO files. I created a bug report about this at "Allow to also commit archives of PO files (instead of single PO files)" http://bugzilla.gnome.org/show_bug.cgi?id=568295 Simos > > On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: >> Hi, >> >> Actually a lot has changed: >> >> - for advanced-translators the same workflow will be maintained. >> - for plain translators a web interface to commit languages will be >> provided. >> >> So I think you fall in the second option and thus you will need to have >> access to http://l10n.gnome.org to download updated po files (like you >> can do right know), track its status (like as of January you can do >> right now) and commit them in source repositories (like you will be able >> to do in a not-so-distant-future, Claude said it has a beta working >> version that does this, I'm right Claude?) >> >> So, all in all, your workflow will be a lot improved since you will only >> have to download and upload files from/to http://l10n.gnome.org :) >> >> Hope I haven't said any lie! >> >> Cheers, >> >> El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure: >>> Hello, >>> >>> I'm really trying to understand the changes. The title sais: >>> Using Git and separating translations into their own l10n-LL repository >>> >>> The title implies that ALL and ONLY po files from ALL the languages UI >>> and HELP will fall into "l10n-LL" repository, but that will not be the >>> case, as I understand. I really don't know why this is so unpopular >>> among developers. >>> >>> I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and >>> also a reminder that I don't fill-in the changelog entries. I can not >>> find those great "scripts" in the gnome archive, that will do all the >>> work in my place, nor can I write one, so doing it step by step is the >>> only way I know. It takes TOO much time, TOO much bandwidth and TOO >>> much space to maintain the language. Putting/linking/sync all po files >>> in one single dir solves many problems for coords like myself. >>> >>> Please, guys, check again if there is a way to do that. Last >>> coordinator dropped out of the translation game because this updating >>> took too much of everything, especially his time. >>> >>> Matej >> -- >> 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 >> >> > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Trying out Git (for translators)
Hi All, There are some instructions at http://live.gnome.org/GitMigration/Translators that describe the commands to use Git. The server git.gnome.org is available for testing (it contains test copies of repositories), and any changes you make will be eventually discarded when the final migration takes place. I think it would be a good opportunity to try out the commands and upload some (dummy) translation updates. If you use Debian/Ubuntu, you need to install the 'git-core' package in order to get the Git commands. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Trying out Git (for translators)
On Mon, Jan 19, 2009 at 7:20 PM, Shaun McCance wrote: > On Mon, 2009-01-19 at 13:40 +0000, Simos Xenitellis wrote: >> Hi All, >> >> There are some instructions at >> http://live.gnome.org/GitMigration/Translators >> that describe the commands to use Git. >> >> The server git.gnome.org is available for testing (it contains test >> copies of repositories), >> and any changes you make will be eventually discarded when the final >> migration takes place. >> >> I think it would be a good opportunity to try out the commands >> and upload some (dummy) translation updates. >> >> If you use Debian/Ubuntu, you need to install the 'git-core' package >> in order to get the Git commands. > > Hi Simos, > > This is really nice. I'd like to offer one tip that people might > find useful. The "git commit" command can optionally take file > names to commit. These are effectively auto-added before commit. > > I don't use "commit -a", because I like to review my work, but > when you just want to commit a single file, as translators would, > "git commit el.po" is easier than "git add el.po; git commit". > > Nothing Earth-shattering. Just thought it would be handy to our > intrepid translators. Hi Shaun, In usability terms, it's a big improvement to eliminate a step. I am updating the wiki page. Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Trying out Git (for translators)
Hello Ihar, My understanding is that the consensus is towards git. I did not notice an announcement that picks officially git in the place of other distributed SCMs. However, since many people are working now on testing git, I assume that this is the direction. I hope this helps, Simos On Mon, Jan 19, 2009 at 7:54 PM, Ihar Hrachyshka wrote: > Maybe I missed something. Is it 100% that Git will be used for Gnome > development? > > On Mon, Jan 19, 2009 at 3:40 PM, Simos Xenitellis > wrote: >> Hi All, >> >> There are some instructions at >> http://live.gnome.org/GitMigration/Translators >> that describe the commands to use Git. >> >> The server git.gnome.org is available for testing (it contains test >> copies of repositories), >> and any changes you make will be eventually discarded when the final >> migration takes place. >> >> I think it would be a good opportunity to try out the commands >> and upload some (dummy) translation updates. >> >> If you use Debian/Ubuntu, you need to install the 'git-core' package >> in order to get the Git commands. >> >> Simos >> ___ >> 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: Using Git and separating translations into their own l10n-LL repository
On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: > Well, I'm sure the devels are able to make the system work in anyway > they choose, that's why I yell so loudly to get all the po files of > one language into one single directory. Now that would cut down the > maintenance. > > If you take a look the translation process, you see, that it consists > of 3 major steps. Acquiring the file(s) to translate, translating and > commiting. > > When you "choose" the file, you have to know what is already > translated, what is reserved, proofed ... or under revision. You also > have to have a quick access to pot files. How many clicks you need to > do that? If it's more than one after visiting the page from your > favorite bar, there is something like click/bandwidth/time, that can > be improved, right? > > Translation by itself is an individual project and has nothing to do > with the git or svn. > > How many times did you "correct" a single word, that was not syncd in > many translations? Last time I did that I had to "repair" 17 files. > Why carry apple by apple from the market if you can take a basket with > you. If you need more than one line in svn/git or one click on the > website more than it's necessary, there is space for improvement, > rignt. Getting the files up and down should mean NO effort. It should > be easier then ftp-ing them to some server. The real work, with all > the logging and diffing, crediting, upgrading and stuff should start > from that point on. > > The last maintainer quit being a mantainer, because he had no time. > The last zip that I sent him for 2.22 some time ago had 83 upgraded > files. If someone sends me 83 files to commit, I'd break down and cry > ... > > Then I'd start again yelling about SINGLE FOLDER for one language. > Less time needed, less bandwidth, less clicks, less nerves, more > translating and proofing. A winning situation. Hi Matej, Earlier in this thread I mention a possible way to have all translations for each language in its own repository (thus, single folder). There where some advantages and disadvantages with this process. I am not sure if you managed to try it using the test repositories from github.com. I believe there is a potential to adapt the proposal so that the disadvantages are eliminated. If you want to have a look at it, it would be great. I'ld be happy to discuss about it. An alternative to the initial proposal of this thread would be to get damned-lies to allow to commit many translation files, as described in the other thread. The bug report is http://bugzilla.gnome.org/show_bug.cgi?id=568295 Simos > On Tue, Jan 20, 2009 at 4:55 PM, Kenneth Nielsen > wrote: >> 2009/1/19 Matej Urban : >>> Thanks, Gil, >>> >>> I will wait and see, but since I'm a translator/mantainer and since I >>> doubt I will be able to upload many files at once, the only difference >>> so far I see, is that I will replace keyboard keystrokes for mouse >>> clicks. There will be no changelog, which is an improvement :) >> >> I don't see how this solution will NOT improve your situation. When >> you want to commit you just have to upload a file via a web-interface. >> Which means that you cut both space and bandwitdth down to a minimum, >> the only thing left is time. You do save the time it takes out to >> check out the modules and fill out the ChangeLog, but you do not get >> to save the time you could if you could commit more files at once. But >> in my opinion that should never be made a possibility (and I'm a >> translation coordinator not a developer), you use verision control >> systems (of any kind) to track changes, which makes it easy to revert >> if you do something wrong, but that hardly makes sense if you commit >> very large changes. >> >> Regards Kenneth >> >> PS: I have a commit script I can send you if you want to use it in the >> meantime, but let me know only if you want to use it as I would have >> to nicefy it a bit before ot could be used by others. >> >>> >>> Anyhow, in the end I will use whatever I'll need to do it, but keep >>> nagging about it. For some reason, I really doubt that single dir for >>> all po files, is a big programing deal. No obsolete clicks, no hassle, >>> just pure translation work. >>> >>> Matej >>> >>> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: >>>> Hi, >>>> >>>> Actually a lot has changed: >>>> >>>> - for advanced-translators the same workflow will be maintained. >>>> - for plain translators
Re: Using Git and separating translations into their own l10n-LL repository
On Thu, Jan 22, 2009 at 9:18 AM, Kenneth Nielsen wrote: > Hey Matej > > 2009/1/22 Matej Urban : >>> Damned lies alrayde have the options download everything from a >>> release set. Look all the way at the bottom of this page: >>> http://l10n.gnome.org/languages/da/gnome-2-26/ui/ >> >> Can I download all the pot files? I'm not aware of it. > > What do you need pot-files for? You will get updated po-files which is > what you need if there already os a translation or a pot-files if > there wasn't already one. And yes you can, just press the button that > says "Download all po files" at the bottom of the page I just sent you > a link for and you will get a tar-ball with all the Danish > po/pot-files. I'm sure you can extrapolate that for you own language. > >> >>>> How many times did you "correct" a single word, that was not syncd in >>>> many translations? >>> >>> Never, because we have a wordlist which we use pretty consistently >> >> That is something we still have to do. But "pretty consistently" tells >> me, that it happens, right. >> >>> Why? It is a task, and as such will require work. >> >> Agreed! But work on translations, not with committing. > > That is part of the task. > >>> In any case, you have already been told that it is certainly possilble to >>> add the >>> option to upload several files at once in Damned Lies, in that case >>> you both have the options to get all files easily and you can have the >>> possibility to commit several files in Damned Lies. The isn't that >>> enough, isn't that exactly what you want, so that we can leave the >>> repositories on their own and in a structure that makes sense i.e. one >>> module-wise. >> >> It would be an improvement, but one folder system would be much >> better. > > Why? If you can commit a tar-ball to Damned Lies with several files in > it in one go (one clicky-di-click) and then they will all be commited > at once, then isn't that exactly the functionality you are asking for? The functionality of being able to submit a single file through the web interface from Damned-lies and make it to GNOME SVN/GIT is not available yet. The ability to submit several files would be an addition to the previous task, and is not available yet either. >> I believe, that It should not be a big deal keeping the >> structure intact and syncing the whole lot with single folder. Maybe >> I'm wrong. > > From what I could read from the previous e-mails about how to use git > with submodules, to link translations in form their own module, it > will be significantly more complex. 'git submodule' is a functionality that was introduced to git quite recently, and the process I described at the start of this thread was indeed complex and most importantly error-prone. So the decision later on in this thread was not to use 'git submodule', in the way described at the start of the thread. Simos > Regards Kenneth Nielsen > >>> Yeah, but perhaps you could have sent him something a little before it >>> reached 83 !?! >> >> I agree, but at that time I was sure, that he only "ftps" them to >> repos and thought, I only did him a favour when sending all at once, >> not giving him too much work ... >> Funny right :) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Ανοιχτή συζήτηση περί των έρ γων μετάφρασης από την εταιρία Ε ΕΛΛΑΚ
Να υπενθυμίσω ότι αν θέλετε να ρωτήσετε κάτι σχετικά με το διαγωνισμό «Πρόσκληση εκδήλωσης ενδιαφέροντος για την Ελληνοποίηση ΕΛΛΑΚ Λογισμικών που είναι χρήσιμα για επιχειρήσεις και την εκπαιδευτική κοινότητα» http://www.ellak.gr/index.php?option=com_openwiki&Itemid=103&id=eellak:metafraseis θα είμαι διαθέσιμος σήμερα το βράδυ (10μμ) στο IRC, Δίκτυο Freenode, κανάλι #gnome-el. http://wiki.ubuntu-gr.org/Wiki/Community/IRC Σίμος ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Ανοιχτή συζήτηση περί των έργων μετάφρασης από την εταιρία ΕΕΛΛΑΚ
2009/1/28 Gintautas Miliauskas : > Ἕλλωυ, > >> Να υπενθυμίσω ότι αν θέλετε να ρωτήσετε κάτι σχετικά με το διαγωνισμό >> «Πρόσκληση εκδήλωσης ενδιαφέροντος για την Ελληνοποίηση ΕΛΛΑΚ Λογισμικών >> που είναι χρήσιμα για επιχειρήσεις και την εκπαιδευτική κοινότητα» >> http://www.ellak.gr/index.php?option=com_openwiki&Itemid=103&id=eellak:metafraseis >> >> θα είμαι διαθέσιμος σήμερα το βράδυ (10μμ) στο IRC, Δίκτυο Freenode, >> κανάλι #gnome-el. >> http://wiki.ubuntu-gr.org/Wiki/Community/IRC >> >> Σίμος > > Ἆι έμ σόρι βάτ ἀί δοῦ νότ ἀνδερστάνδ θίσ; That's amazing! Phonetic Greek Polytonic that corresponds to «I am sorry but I do not understand this». I am stupid, instead of announcing at i18...@hellug.gr, GMail put the address for this gnome-i18n mailing list. Sorry for the mix-up, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GTK+ "sdl|system" message
There is a bug report already for this, http://bugzilla.gnome.org/show_bug.cgi?id=513422 I am adding a comment to convert to msgctxt. Simos On Sun, Feb 1, 2009 at 9:16 AM, Александър Шопов wrote: > There is a message in gtk+ po-file: > #: ../gdk/directfb/gdkdisplay-directfb.c:55 > msgid "sdl|system" > > Is this a non migrated context, thus I should translate only "system" or > is this the whole message and what does it mean then? > > Kind regards: > al_shopov > > > ___ > 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: Translating panel clock format
Per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=140891&msg=47 it mentions that the glibc locale policy is that am_pm information will be blank if the country does not official support AM/PM to signify the time. This leads to problems of programs allowing to show the time in a 12-hour format while nothing shows whether it's AM or PM. Personally, I would feel that the glibc locales should always have the localised am_pm information and let the end-user choose. However, per Libc policy, you would simply remove the option for 12-hour/24-hour time and simply check if "am_pm" is empty or not. Simos On Wed, 2005-02-02 at 09:30, Christian Rose wrote: > ons 2005-02-02 klockan 08:19 + skrev Mark McLoughlin: > > In gnome-panel, translators can translate the strings "24" and > > "24-hour" to "12"/"24" and "12-hour"/"24-hour" depending on whether a 12 > > or 24 hour clock is the norm in that locale. > > > > Unfortunately, its easy to miss the fact that you're not supposed to > > translate these values like other strings, so you get the likes of: > > > > msgid "24-hour" > > msgstr "24 sata" > > > > Which neither the panel nor gconftool-2 can understand. > > > > There are comments in the po file explaining the situation: > > > > #. Translators: the only valid values for this are "12-hour" and "24-hour" > > #: applets/clock/clock.schemas.in.h:4 > > > > But I guess its easy to miss that. I don't have any other ideas how to > > make this foolproof, though. > > Really, translators should be more careful, but perhaps stressing the > fact even more in the comment and making the comment slightly more > verbose and explanatory would help somewhat: > > /* Translators: This controls whether the GNOME panel clock should >display time in 24 hour mode or 12 hour mode by default. The only >valid values for this are "24-hour" and "12-hour". If your locale >uses 24 hour time notation, translate this to "24-hour". If your >locale uses 12 hour time notation with am/pm, translate this to >"12-hour". > >Do NOT translate this into anything else than "24-hour" or >"12-hour". For example, if you translate this to "24 sata" or >anything else that isn't "24-hour" or "12-hour", things will >not work. */ > > > Christian > > ___ > 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: access keys
ÎÏÎÏ 23/ÎÎÎ/2005, ÎÎÎÏÎ ÎÎÏÎÏÏÎ ÎÎÎ ÏÏÎ 14:28, Î/Î Nikos Charonitakis ÎÎÏÎÏÎ: > hi > is there any automatic way to check and arrange access keys in an > application? Can you give an example for this? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: evolution, evolution-data-server, evolution-exchange, gal branched
ÎÏÎÏ 01/ÎÎÏ/2005, ÎÎÎÏÎ ÎÏÎÏÎ ÎÎÎ ÏÏÎ 08:33, Î/Î JP Rosevear ÎÎÏÎÏÎ: > These modules have all branched (gnome-2-10) for GNOME 2.10. Who is updating at CVS://gnome-i18n so that it is reflected on http://l10n-status.gnome.org/gnome-2.10/el/desktop/index.html ? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translating release notes
ÎÏÎÏ 22/ÎÎÎ/2005, ÎÎÎÏÎ ÎÏÎÏÎ ÎÎÎ ÏÏÎ 13:03, Î/Î Davyd Madeley ÎÎÏÎÏÎ: > On Tue, 2005-02-22 at 10:36 +0100, Murray Cumming wrote: > > > > Besides i'm wondering if it's possible to prepare a gimp script-fu and > > > give them to translators in order to make localized screen shots of the > > > ones in what's new section of release notes. Or is it only drop shadow > > > and fuzzy edges? > > > > Davyd? > > Everything I use for screenshots is available with the standard Gimp > package. I'm going to try and write down some notes on what I did to > capture each image. > > Shouldn't be anything too hard I imagine. I can figure out most of the work (http://www.livejournal.com/users/simos74/32918.html) but one piece is missing. 1. You use GIMP to take the screenshots. 2. You add an alpha channel 2. You crop/remove the part that is not needed so there is nice transparency to whatever is left out. 4. You select the image. 5. You apply the ScriptFu plugin "Drop Shadow". The part I am missing is how you make the blending in, with transparency. Especially usefull if you do not want to show the whole window but part of it. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translating release notes
ÎÏÎÏ 04/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÎÏÎÎÏÎ ÎÎÎ ÏÏÎ 17:32, Î/Î Danilo Åegan ÎÎÏÎÏÎ: > Today at 12:46, Martin Willemoes Hansen wrote: > You won't have to update your translations, and I've checked Greek > translation with Yelp which still seems complete. How many are the strings in total? 243 or 260? Currently our el.po shows 260, I'll read up again the post about how to fix manually and complete it. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Guide on how to edit screenshots for shadow and blending
Hi All, I created two guides on how to edit screenshots to subsequently add to the release notes. The guides are heavily influenced by Davyd's screenshots. 1. How to drop shadow http://planet.hellug.gr/misc/rec_dropshadow.html (for menus, reduce offset from 5, to 3). 2. How to do blending on the previous image http://planet.hellug.gr/misc/rec_dropshadowblend.html I hope they are usefull, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Does gweather (gnome-applets) work for you?
Hi, We (Greek Localisation Team) have some trouble getting gweather to run on the latest build of GNOME 2.10 (-soon to be). The application crashes as soon as it runs and the stack trace gives little info (no debugging): > > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > [Thread debugging using libthread_db enabled] > > [New Thread -1221689216 (LWP 9019)] > > 0xe410 in ?? () > > #0 0xe410 in ?? () > > #1 0xbfffe9ac in ?? () > > #2 0x in ?? () > > #3 0xbfffe90c in ?? () > > #4 0xb7db1413 in __waitpid_nocancel () > >from /lib/tls/i686/cmov/libpthread.so.0 > > #5 0xb7f8dd97 in libgnomeui_module_info_get () > >from /usr/lib/libgnomeui-2.so.0 > > #6 > > #7 0xce9cce93 in ?? () > > #8 0xce9dce95 in ?? () > > #9 0x00a3ce95 in ?? () > > #10 0x081efe40 in ?? () > > #11 0x081157e8 in ?? () > > #12 0x081f0190 in ?? () > > #13 0x081efbc0 in ?? () > > #14 0xbfffecb8 in ?? () > > #15 0x081157e8 in ?? () > > #16 0x081efe40 in ?? () > > #17 0x081efd80 in ?? () > > #18 0x081effd0 in ?? () > > #19 0x08114a28 in ?? () > > #20 0x08114a28 in ?? () > > #21 0x08114a54 in ?? () > > #22 0xbfffecf8 in ?? () > > #23 0x08051806 in gweather_pref_load (gw_applet=0xce9dcea5) > > at gweather-pref.c:1144 I think this looks like a problem loading the preferences, and in the case of gweather it might be those strings like msgid "DEFAULT_RADAR" msgstr "" Since countries outside the US (and Canada?) do not have a RADAR value, I have seen a lot of values here (like "This is not applicable", "", " ") and so on. It looks possible that a crash is caused because due to unexpected input handling. I have not managed to try myself to remove the translation altogether (but keep LANG=el_GR.UTF-8) to see if it still happens, as I have not installed GNOME 2.10pre... Could someone else who has GNOME 2.10(almost there) to try out gweather and see if it actually works for them? Please report back your $LANG and if it works. If possible, try different values for $LANG to help others. Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translating release notes: number of supported languages changed
ÎÏÎÏ 06/ÎÎÏ/2005, ÎÎÎÏÎ ÎÏÏ ÎÎÎ ÏÏÎ 15:22, Î/Î Jordi Mallach ÎÎÏÎÏÎ: > On Sun, Mar 06, 2005 at 03:27:21PM +0100, Danilo Åegan wrote: > > Also, I'm a bit disappointed to see that the total number of supported > > languages has gone down from 40 in Gnome 2.8 (at the time of release, > > now it's 44) and 36 in Gnome 2.6. I hope many will continue improving > > their 2.10 translations, so we can see better support in 2.10.1. > > If a team doesn't translate gnome-applet-locations at all, and the rest > is at 100%, I think all you can get is a 79% percent. That is a big > pitty, because most of those strings are the less useful in the whole > suite. There was a discussion on this list on how to autofill the gnome-applets-locations domain with msgstr=msgid (that's 'copy'), if the message is not already translated. I am not sure if a script has been developed in the meanwhile. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Release Notes translation without screenshots
ÎÏÎÏ 06/ÎÎÏ/2005, ÎÎÎÏÎ ÎÏÏ ÎÎÎ ÏÏÎ 15:35, Î/Î Raphael Higino ÎÎÏÎÏÎ: > Hi guys, > > Is there any problem if one translates Release Notes and doesn't make > 'translated' screenshots? Would the translated Release Notes be shown with > original screenshots? You will have to copy them in your xml-pt_BR/figures folder and the default screenshots will work for you. > Just trying my luck, I don't think I'll have the necessary resources to make > the screenshots (install GNOME 2.10 pre, find someone to edit the images, > time at all). So, is there someone who could take them for me with > LANG=pt_BR if I got to translate all text? It would be indeed nice if someone showed up to take the screenshots. It's rather easy to latter edit them (see: planet.hellug.gr/misc/rec_dropshadow.html and planet.hellug.gr/misc/rec_dropshadowblend.html) If the screenshots are good, it should take less than an hour to edit them and get them look nice. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New external dependency: iso-codes ?
ÎÏÎÏ 07/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÏÎÏÎ ÎÎÎ ÏÏÎ 20:15, Î/Î Christian Persch ÎÎÏÎÏÎ: > Hi, > > I'd like to add a new external dependency to GNOME Desktop: the > "iso-codes" package. It's available from cvs > [http://alioth.debian.org/projects/pkg-isocodes/] and tarball > [http://people.debian.org/~mckinstry/iso-codes-0.45.tar.gz]. > > Using this package will remove the duplicated translations of language > and country names from GNOME programs. Epiphany and Galeon already have > support for iso-codes (optional dependency atm), and there's a bug with > patch to make gedit's spell-check using it too > [http://bugzilla.gnome.org/show_bug.cgi?id=150535]. > > If nobody objects, I'm going to go ahead and make it a hard dependency > for Epiphany, and add the module to the gnome-2.12 jhbuild moduleset. The ISO codes package is being translated under the Translation Project (http://www.iro.umontreal.ca/translation/HTML/index.html) and listed at http://www.iro.umontreal.ca/translation/registry.cgi?domain=index See the iso translation domains in the middle of the page. The relation between the two (Translation Project and iso-codes) is that the former is higher upstream. Translators deal with the Translation Project and regularly the guy from Debian makes a release of the translations. Is that correct? Another package from the Translation Project, xkeyboard-config is used by gswitchit, the keyboard switching tool in GNOME, to provide the names of the keyboards in the local language. I am not sure if such a dependancy exists already. Sergey (author of gswitchit)? It looks more canonical to me to make the dependancy to the Translation Project. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New external dependency: iso-codes ?
ÎÏÎÏ 07/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÏÎÏÎ ÎÎÎ ÏÏÎ 21:54, Î/Î Danilo Åegan ÎÎÏÎÏÎ: > Hi Simos, > > Today at 22:01, Simos Xenitellis wrote: > > > It looks more canonical to me to make the dependancy to the Translation > > Project. > > You got it a bit mixed up :) > > Translation Project (TP) is basically for other programs what GTP is > for Gnome: a translation project. You cannot "add a dependency" on > GTP for any software module, because it's not software, it's a group > of people and some infrastructure :) > > The discussion here was whether to make iso-codes build- and run-time > dependencies of Gnome software. That can be done several ways, and > one is to make it a "soft" dependency (everything would work fine even > if it's not there, except there might be no translations), or "hard" > dependency (package won't install if a hard dependency is not > installed). > > For example, xkeyboard-config translations are a soft dependency of > Gnome keyboard preferences: you get untranslated layout names if > xkb-config is not included. Thanks for the clarification and the part on soft/hard dependencies. The translators indeed send their work to the Translation Project, so for the latest Greek version for the iso_639 translation domain, one would have to look in http://www.iro.umontreal.ca/translation/teams/PO/el/ However, it's simple to delegate the collection of the latest PO files to the iso-codes maintainer and interact with him, rather than scanning ourselves (as GTP) for any latest version. The iso-codes maintainer is not the highest upstream, but's he is high enough for the purposes of GNOME. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Does gweather (gnome-applets) work for you?
ÎÏÎÏ 07/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÏÎÏÎ ÎÎÎ ÏÏÎ 23:51, Î/Î Abel Cheung ÎÎÏÎÏÎ: > On 2005-03-06(Sun) 17:25:44 +0200, Nikos Charonitakis wrote: > > On Sun, 06 Mar 2005 15:10:09 +0000, Simos Xenitellis <[EMAIL PROTECTED]> > > wrote: > > > > > > Hi, > > > We (Greek Localisation Team) have some trouble getting gweather to run > > > on the latest build of GNOME 2.10 (-soon to be). > > > > > > The application crashes as soon as it runs and the stack trace gives > > > little info (no debugging): > > > > > > I think this looks like a problem loading the preferences, and in the > > > case of gweather it might be those strings like > > > > > > msgid "DEFAULT_RADAR" > > > msgstr "" > > I have removed a CVS conflict mark inside el.po, please pick it from CVS > and test if this problem persists? Many thanks Abel for catching the CVS conflict. The problem described at http://bugzilla.gnome.org/show_bug.cgi?id=169386 does not persist anymore and we are closing the issue. Our mistake was with the interpretation of default variables such as DEFAULT_ZONE. No such thing exists for countries apart from US and Canada, and the translator comments are not helpful at all. May I add something along the lines of the following translator comment to the DEFAULT_xxx variables? /* If the following variable does not apply to your country/airport, simply replicate the msgid entry. Do not try to translate verbatim or innovate, else you will create a greek tragedy. See http://bugzilla.gnome.org/show_bug.cgi?id=169386 for more. Even what you put says DEFAULT_xxx, it's not anything default. It's an indication to the program to keep it empty and unused. Sabes? */ Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
URL for localised release notes?
Hi All, In the Greek version of the press release we are considering to put a direct link (URL) to the Greek release notes. Is that URL known already? Something like http://www.gnome.org/start/2.10/el/ ? We would like to finalise the release notes by tomorrow. Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GNOME Linux Live CD - Language support question
Hi, We (Greek Localisation Team) are considering to distribute GNOME LiveCD along with the press release. I have not downloaded the CD yet, so my question is, are there languages other than English included? The full support of languages just for GNOME looks to be around 100MB (?). So, if the LiveCD that Luis is working on does not have languages apart from English, is anyone interested/(already done) to make custom language CDs? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [Release notes]What is 100%?
ÎÏÎÏ 09/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÎÏÏÎ ÎÎÎ ÏÏÎ 14:58, Î/Î Vincent van Adrighem ÎÎÏÎÏÎ: > Hi all, > > The Dutch team has translated the release notes. But even though it's > 100% on my setup, murrayc and jdub say it's not completely translated. Where do you get the info for "murrayc and jdub say it's not completely translated."? Posting? Wiki? > I'd like to find out why. > nl.po: 152 translated message, 1 fuzzy translation, 89 untranslated > messages > > I've checked out a fresh copy of the release notes (cvs co > releng/2.x/2.10rnotes) > and the xml2po utility (cvs co gnome-doc-utils). > Installed xml2po on my debian unstable box (to /usr/local). Good. I suppose they are today's copies. Did you make sure that the new xml2po is used? Type "which xml2po" as you may use another older system version. > entered the directory releng/2.x/2.10rnotes/po and did a make: > === >Translation statistics > === > da.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > de.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > el.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. I get 242 messages. > es.po:1486:66: invalid multibyte sequence > msgfmt: found 6 fatal errors > et.po: 126 translated messages, 1 fuzzy translation, 33 untranslated > messages. > fr.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > id.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > it.po: 21 translated messages, 139 untranslated messages. > ja.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > nb.po: 35 translated messages, 7 fuzzy translations, 118 untranslated > messages. > nl.po: 159 translated messages, 1 fuzzy translation. > pa.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > pt_BR.po: msgfmt: pt_BR.po: warning: Charset missing in header. >Message conversion to user's charset will not > work. > msgfmt: too many errors, aborting > sq.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > sr.po: 56 translated messages, 11 fuzzy translations, 93 untranslated > messages. > sv.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > th.po: 151 translated messages, 1 fuzzy translation, 8 untranslated > messages. > uk.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > zh_TW.po: 152 translated messages, 1 fuzzy translation, 7 untranslated > messages. > > The total number of translations seems to be 160. And nl.po is almost > done (1 fuzzy). Is there anything I'm missing here? I'd really > appreciate some help. > > If anyone can shed any light on the matter, I'd be really grateful. I tried just now and I got: === Translation statistics === da.po: 242 translated messages. de.po: 241 translated messages, 1 untranslated message. el.po: 242 translated messages. es.po: es.po:283:55: invalid multibyte sequence es.po:392:45: invalid multibyte sequence es.po:1064:2: invalid multibyte sequence es.po:1202:9: invalid multibyte sequence es.po:1430:51: invalid multibyte sequence es.po:1486:66: invalid multibyte sequence msgfmt: found 6 fatal errors et.po: 212 translated messages, 2 fuzzy translations, 28 untranslated messages. fr.po: 242 translated messages. id.po: 241 translated messages, 1 fuzzy translation. it.po: 63 translated messages, 178 untranslated messages. ja.po: 240 translated messages, 2 fuzzy translations. nb.po: 76 translated messages, 7 fuzzy translations, 159 untranslated messages. nl.po: 160 translated messages. pa.po: 241 translated messages. pt_BR.po: 227 translated messages, 14 untranslated messages. sq.po: 241 translated messages. sr.po: 105 translated messages, 17 fuzzy translations, 120 untranslated messages. sv.po: 242 translated messages. th.po: 216 translated messages, 26 untranslated messages. uk.po: 241 translated messages, 1 fuzzy translation. zh_CN.po: msgfmt: zh_CN.po: field `Project-Id-Version' still has initial default value msgfmt: found 1 fatal error zh_TW.po: 241 translated messages. There is some housekeeping that needs to take place, such as fixing the header for zh_CN.po, converting from iso-8859-1 to utf-8 for the Spanish translation. Also, ISDN can be fixed without translation intervention. Would it be ok if I touched these? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GNOME Linux Live CD - Language support question
ÎÏÎÏ 11/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÎÏÎÎÏÎ ÎÎÎ ÏÏÎ 16:17, Î/Î Luis Villa ÎÎÏÎÏÎ: > Simos- > I've responded to your comments in the wiki about language support, I > hope that is useful. Thanks, Luis. I read the comments on the Wiki page for language support. (http://live.gnome.org/GnomeLiveCd_2fLiveDiscussion) We will go soon for a custom LiveCD as described below in (2). Simos > I definitely expect in the future: > > (1) that the 'stock' CDs produced for releases will have the > most-spoken several languages, keeping in mind that we have to > localize not just GNOME but also the installer and mozilla (and > probably OOo for the near-term as well.) I believe the first release > had something like 11 languages, but I honestly forgot to check before > release- we'll make it part of the release in the future. > > (2) that it should be stupidly easy for local language groups to > produce custom liveCDs. There are a couple open items on the > http://live.gnome.org/GnomeLiveCd_2fToDo page about this; anyone who > wants to look into them (I hope someone from gnome-i18n will, as I > don't have time right now) would be more than welcome to do so. I > believe that once the questions in the ToDo are resolved it would be > quite easy for any localization group to produce a fully localized CD. > > Luis > > > On Fri, 11 Mar 2005 17:08:11 +0100, Murray Cumming <[EMAIL PROTECTED]> wrote: > > On Wed, 2005-03-09 at 15:38 +, Simos Xenitellis wrote: > > > Hi, > > > We (Greek Localisation Team) are considering to distribute GNOME LiveCD > > > along with the press release. > > > > > > I have not downloaded the CD yet, so my question is, are there languages > > > other than English included? > > > > I think there are non-english languges included, and it does ask you to > > choose a language when it starts. Luis and the marketing list are the > > people who would know best. > > > > > The full support of languages just for GNOME looks to be around 100MB > > > (?). > > > > > > So, if the LiveCD that Luis is working on does not have languages apart > > > from English, is anyone interested/(already done) to make custom > > > language CDs? > > > > -- > > Murray Cumming > > [EMAIL PROTECTED] > > www.murrayc.com > > www.openismus.com > > > > -- > > marketing-list mailing list > > marketing-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/marketing-list > > > ___ > 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: Re[2]: GNOME Translation in Uighur [ug]: Help needed
ÎÏÎÏ 14/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÏÎÏÎ ÎÎÎ ÏÏÎ 14:14, Î/Î Funda Wang ÎÎÏÎÏÎ: > Abdurixit> But in this way I can resolve only one of the four different > Abdurixit> presentation forms. > Abdurixit> so that I can resolve all the existing forms with one key and it > Abdurixit> changes from one form to the other according to the previous > Abdurixit> and next letter in the word as I type. > If those four different presentation forms have different Unicode > mapping, you might want to use IME rather than a xkb method. A IME > method is, you will get international characters while inputting via > standard en keyboard. A xkb method is something like a piple, which will > convert what you input directly into corresponding Unicode characters. > > The widely used IME platform nowadays are iiimf[1] and scim[2]. > Personally, I don't know whether it is easy or difficult writing a new > IM under iiimf. AFAIK, with all the language materials provided, you > can write a new IM under scim within two days. It shouldn't be to diffucult for IIIMF either. Have a look at http://anakin.ncst.ernet.in/~aparna/consolidated/x2005.html I suppose you could start by using Arabic as an example. No need to compile IIIMF either, as most distros have packages (Fedora, Debian, Ubuntu, etc). Simos > [1]: http://fedora.redhat.com/projects/i18n/iiimf-faq.html > [2]: http://www.scim-im.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Web-based translation for GNOME
Hi All, This question is about enabling web-based translation tools (such as Pootle http://pootle.wordforge.org/, etc) to translate GNOME. I am asking to get some feedback in the sense of "ok, not bad" or "no!! wrong direction. Burn!". A Web-based translation tool is supposed to do the hard job of finding the .po files, allowing the user to translate in a friendly Web-based interface, and potentially commit automatically back to GNOME CVS. To get Web translation tools to attach to GNOME CVS, the tool can either maintain a local copy of GNOME CVS, or use the POT/PO files from http://l10n-status.gnome.org/ The former provides completeness, the latter allows easier independent local installations around the world. Using http://l10n-status.gnome.org/ as input looks very promising, and this is what I am asking your opinion about. Option A is to have Web-translation tools to grab .po/.pot files from the statistics pages, let translate and then somehow manually update GNOME CVS. Option B is to have the tool do the whole job automagically, including CVS commits. Some details == a. The Web-translation tool would first be configured to work on languages that the team leader says it's ok. http://developer.gnome.org/projects/gtp/teams.html to be used for the permission issue. b. The stat pages contain complete information to locate the .po/.pot files, such as branch, folder, location of .po files and so on. That info could be parsed from HTML. Any suggestions to have some other format for these data, that's easier to parse? c. There will be a dependancy to the structure of the HTML pages, unless again there is some sort of XML file, listing the complete information of the translation files. d. Web-translation tools could commit the changes using either a common CVS account (for example, for Pootle, you can either translate through the main installation at http://pootle.wordforge.org/ or install it on your own), or have team leaders (that want to do Web-based translation) put their username/password in the Web-translation system. Regards, Simos Xenitellis http://simos.info/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [translate-pootle] Re: Web-based translation for GNOME
ÎÏÎÏ 16/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÎÏÏÎ ÎÎÎ ÏÏÎ 13:58, Î/Î Danilo Åegan ÎÎÏÎÏÎ: > Hi Simos, > > Just to be clear: something like this should *not* be obligatory for > Gnome translation work (even though you never implied it would be, I'm > putting a disclaimer here :). Ack. As Dwayne said, the translation management tools are to help translation teams that want to use them. > While I think having web-based translation tool would be excellent for > official GTP, I find Pootle quite lacking in features. > > Today at 14:35, Simos Xenitellis wrote: > > > b. The stat pages contain complete information to locate the .po/.pot > > files, such as branch, folder, location of .po files and so on. That > > info could be parsed from HTML. Any suggestions to have some other > > format for these data, that's easier to parse? > > c. There will be a dependancy to the structure of the HTML pages, unless > > again there is some sort of XML file, listing the complete information > > of the translation files. > > Look at gnome-i18n/status/data/translation-status.xml file for your > input. At some times, l10n-status gets out of sync (between updates, > when someone does some changes to translation-status.xml), but that > shouldn't be too big of a problem. Is there a generated .xml file that lists all the .po files, for example, for the Greek language? I suppose one would then use the following. Using the existing translation-status.xml, if a translation management tool wanted to work on the .po files for gnome-utils, release 2.10, it would parse the .xml file, then using: it would test if http://l10n-status.gnome.org/gnome-2.10/PO/gnome-utils.gnome-2-10.el.po [BASEURL+COMPONENTNAME+"."+BRANCHNAME+"."+LL+".po"] exists (so there is existing translation) and use it to continue translations. If the URL does not exist, it would load up http://l10n-status.gnome.org/gnome-2.10/PO/gnome-utils.gnome-2-10.pot [BASEURL+COMPONENTNAME+"."+BRANCHNAME + ".pot"] and start an initial translation. In addition to this, my initial concern is whether a translator (or a translation management tool) should use the .POT and .PO files from http://l10n-status.gnome.org/ rather than checking out all of GNOME CVS. It's quite tempting to use the files from http://l10n-status.gnome.org/ and base whatever tools are created on them. > Another approach is to use jhbuild modulesets files (Carlos has been > planning to use them for still unfinished new status pages). > > > d. Web-translation tools could commit the changes using either a common > > CVS account (for example, for Pootle, you can either translate through > > the main installation at http://pootle.wordforge.org/ or install it on > > your own), or have team leaders (that want to do Web-based translation) > > put their username/password in the Web-translation system. > > Or perhaps simply e-mail the coordinator who would be able to commit > it on their own? That's a completely valid option, and the one I > would most likely use if I end up using it at all. Ack. My personal preference would be to setup something like a https://www.gnome.gr/translate/ that would allow from a Web-interface to complete remaining translations (typically 5-20 messages) and have them moved upstream automatically. No need to manually cvs checkout, no emacs to edit ChangeLog, no manuall commit. In another setting, one would download initially a snapshot of the .po files for a specific language to work offline on them, have a weekend-long translation fest on the local network (thus responsive interface), manually verify the work for correctness and finally click on "Move upstream" to send off in one go to GNOME CVS. Or simply commit manually. Simos Xenitellis http://simos.info/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: update-manager added to stats
ÎÏÎÏ 21/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÏÎÏÎ ÎÎÎ ÏÏÎ 11:12, Î/Î Martin Willemoes Hansen ÎÎÏÎÏÎ: > sÃn, 20 03 2005 kl. 19:47 +0100, skrev Danilo Åegan: > > Today at 18:53, Martin Willemoes Hansen wrote: > > > > > Could update-manager be added to l10n-status.gnome.org > > > > Certainly, any software that sits in Gnome CVS automatically qualifies > > for our status pages, since GTP is in charge of it. > > > > Care to add it yourself? :) > > Sure, I guess its just an update to translation-status.xml. > Now do I need to do anything else than updating that file? > > BTW, it seems to be added now by Christian Rose. To add here, any program that is in GNOME CVS can be added to the status pages, under HEAD, in the most relevant group of either "fifth-toe", "office" or "extras". Most probably it will go in "extras", which can be considered as incubator for the selection of the program by the release team to upgrade to a GNOME release (such as the forthcoming GNOME 2.12). Therefore, when one adds a program to the status pages, s/he can announce "I added update-manager to the GNOME translation status pages, under HEAD/extras". :) Simos Xenitellis ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: How to show the same program with two different language sets?
Roberto wrote: Hi guys, I'm trying to give my contribution to some italian translations. I need a way to start the same prog (the one I'm translating) both in english and in italian so that I can better understand where some terms appear and make a better translation. I tried starting a terminal, then exporting LANG variable to en_US (tried en_GB too :-) and then starting 'yelp' (this is one of the program, whose .po I'm translating) but Yelp still runs in italian (my language default for the Gnome desktop I use). The same procedure works with some other software (gqView, Xmms, The GIMP) and I can compare the appearance of every string both in english and in italian. Are Gnome applications (like Yelp) getting their language environment elsewehere? What am I doing wrong? Any hint? What distro? Some distros (namely Ubuntu Linux) set the LANGUAGE variable that takes precedence over LANG. Therefore, change LANGUAGE between "it" and "en". Simos Xenitellis -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 21/03/2005 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
gweather Locations.xml in GNOME 2.10, does it work for you?
Hi All,
I just installed Ubuntu Hoary preview and had a look at the translation
work.
I noticed that there might be a back in gweather, and specifically in
the translations that come from Locations.xml (names of
cities/locations/airports).
It appears that the country names are shown properly (if they have been
translated). However, all other names (locations, cities) are shown in
English, as if the XML file is not further parsed.
Could someone else verify ("me too" or "works for me") that the
city/location/airport names are shown in the local language?
If it's indeed a problem, I'll write a bug report.
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gweather Locations.xml in GNOME 2.10, does it work for you?
ÎÏÎÏ 24/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÎÏÏÎ ÎÎÎ ÏÏÎ 00:05, Î/Î
Vincent van Adrighem
ÎÎÏÎÏÎ:
> Op wo, 23-03-2005 te 23:41 +, schreef Simos Xenitellis:
> > Hi All,
> > I just installed Ubuntu Hoary preview and had a look at the translation
> > work.
> > I noticed that there might be a back in gweather, and specifically in
> > the translations that come from Locations.xml (names of
> > cities/locations/airports).
> >
> > It appears that the country names are shown properly (if they have been
> > translated). However, all other names (locations, cities) are shown in
> > English, as if the XML file is not further parsed.
> >
> > Could someone else verify ("me too" or "works for me") that the
> > city/location/airport names are shown in the local language?
>
> Well, I'm running Ubuntu hoary, and it works for me. I'm getting Dutch
> (nl) translations for the Dutch cities. Please check that you've
> installed the language-support- and language-pack- packages
> for your locale. Also, check the po-file by hand. You can "msgunfmt" it
> to check if it's in there at all..
For the case of the airport/city/location names, they are stored in
/usr/share/gnome-applets/gweather/Locations.xml
I verified that the applet reads succesfully the file (using "strace"),
however it only shows the names of the countries in Greek but not the
locations or cities.
Could you please verify specifically that when you look for "Athens"
(Europe/Greece/"Athens"), it shows it indeed in Danish, that is, as
"Athen" (without ending "s")?
Simos Xenitellis
p.s.
Thanks Arangel for the "me too".
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gweather Locations.xml in GNOME 2.10, does it work for you?
ÎÏÎÏ 24/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÎÏÏÎ ÎÎÎ ÏÏÎ 02:25, Î/Î Vincent van Adrighem ÎÎÏÎÏÎ: > Op do, 24-03-2005 te 02:15 +, schreef Simos Xenitellis: > > For the case of the airport/city/location names, they are stored in > > /usr/share/gnome-applets/gweather/Locations.xml > > I verified that the applet reads succesfully the file (using "strace"), > > however it only shows the names of the countries in Greek but not the > > locations or cities. > > > > Could you please verify specifically that when you look for "Athens" > > (Europe/Greece/"Athens"), it shows it indeed in Danish, that is, as > > "Athen" (without ending "s")? > > > > Simos Xenitellis > > > > p.s. > > Thanks Arangel for the "me too". > Well, I should have double checked before I opened my big mouth. :) > > It looks like the cities don't get translated. Athens shows up as > "Athens", but should show up as "Athene" in Dutch (nl). > > So, my works-for-meâ is hereby changed to a me-tooâ. Ack. Raphael verified for Portuguese and I also checked with Spanish. I submitted a bug report at http://bugzilla.gnome.org/show_bug.cgi?id=171444 Unfortunatelly, my test system is too slow for compiling. If you can compile and narrow down the problem, you can try the following tips: http://www.davyd.id.au/articles/debugging-gnome-applets.shtml I hope the bug gets resolved before distributions with GNOME 2.10 start shipping. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Currencies list?
Murray Cumming wrote: Does anyone know of a LGPL (or similar) library that can give me a (translatable) list of currencies (with symbol, name, and country)? I would like to use this for the numeric formatting options in Glom. The currency codes and names are listed in ISO 4217, see: http://www.iso.org/iso/en/prods-services/popstds/currencycodes.html http://www.xe.com/iso4217.htm What programming language are you interested in? I suppose C? There is already a textual domain for currency names, maintained at the Translation Project: http://www.iro.umontreal.ca/translation/registry.cgi?domain=iso_4217 Simos -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 27/03/2005 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Currencies list?
ÎÏÎÏ 29/ÎÎÏ/2005, ÎÎÎÏÎ ÎÏÎÏÎ ÎÎÎ ÏÏÎ 19:49, Î/Î
Christian Rose ÎÎÏÎÏÎ:
> tis 2005-03-29 klockan 17:41 +0200 skrev Murray Cumming:
> > On Tue, 2005-03-29 at 16:32 +0100, Simos Xenitellis wrote:
> > > Murray Cumming wrote:
> > >
> > > >Does anyone know of a LGPL (or similar) library that can give me a
> > > >(translatable) list of currencies (with symbol, name, and country)? I
> > > >would like to use this for the numeric formatting options in Glom.
> > >
> > > The currency codes and names are listed in ISO 4217, see:
> > > http://www.iso.org/iso/en/prods-services/popstds/currencycodes.html
> > > http://www.xe.com/iso4217.htm
> > >
> > > What programming language are you interested in? I suppose C?
> >
> > Yes, C/C++.
> >
> > > There is already a textual domain for currency names, maintained at
> > > the Translation Project:
> > > http://www.iro.umontreal.ca/translation/registry.cgi?domain=iso_4217
> >
> > Thanks, but I'm not sure how I should use this in my application.
> >
> > For instance
> > - how could I get a list of currencies.
> > - how could I get a translation of a currency name, in the current
> > locale?
>
> The iso* domains in the Translation Project are what translators see of
> the "iso-codes" package (see
> http://people.debian.org/~mckinstry/iso-codes-0.45.tar.gz). That package
> contains XML files with some or all of the information you list above.
> As I understand it, you should be able to depend on that package, and
> get the translations from it.
The above URL does not seem to work at the moment. You can try
http://packages.debian.org/unstable/misc/iso-codes
To use the textual domain, I copy from the README file of the package:
``Currently there are lists of languages and countries embedded in:
- Gnome Libs
- bootfloppies / PGI
- KDE
- Gnumeric
- Gnucash
- ...''
``So the plan is then to be able to use
dgettext("iso-639", language_name)
to get the correct translations.''
In addition, it recommends to contact the maintainer of the iso-codes
package when you are considering to make an implementation, as the
current format is in flux.
Kexchange (http://www.favorin.com/projects/kexchange/) does not make use
of iso-codes but rather translates again the currency names.
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Currencies list?
Some more information on currency internationalisation...
http://www.xencraft.com/resources/multi-currency.html#group
Simos
ÎÏÎÏ 30/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÎÏÏÎ ÎÎÎ ÏÏÎ 06:34, Î/Î
Simos Xenitellis
ÎÎÏÎÏÎ:
> ÎÏÎÏ 29/ÎÎÏ/2005, ÎÎÎÏÎ ÎÏÎÏÎ ÎÎÎ ÏÏÎ 19:49, Î/Î
> Christian Rose ÎÎÏÎÏÎ:
> > tis 2005-03-29 klockan 17:41 +0200 skrev Murray Cumming:
> > > On Tue, 2005-03-29 at 16:32 +0100, Simos Xenitellis wrote:
> > > > Murray Cumming wrote:
> > > >
> > > > >Does anyone know of a LGPL (or similar) library that can give me a
> > > > >(translatable) list of currencies (with symbol, name, and country)? I
> > > > >would like to use this for the numeric formatting options in Glom.
> > > >
> > > > The currency codes and names are listed in ISO 4217, see:
> > > > http://www.iso.org/iso/en/prods-services/popstds/currencycodes.html
> > > > http://www.xe.com/iso4217.htm
> > > >
> > > > What programming language are you interested in? I suppose C?
> > >
> > > Yes, C/C++.
> > >
> > > > There is already a textual domain for currency names, maintained at
> > > > the Translation Project:
> > > > http://www.iro.umontreal.ca/translation/registry.cgi?domain=iso_4217
> > >
> > > Thanks, but I'm not sure how I should use this in my application.
> > >
> > > For instance
> > > - how could I get a list of currencies.
> > > - how could I get a translation of a currency name, in the current
> > > locale?
> >
> > The iso* domains in the Translation Project are what translators see of
> > the "iso-codes" package (see
> > http://people.debian.org/~mckinstry/iso-codes-0.45.tar.gz). That package
> > contains XML files with some or all of the information you list above.
> > As I understand it, you should be able to depend on that package, and
> > get the translations from it.
>
> The above URL does not seem to work at the moment. You can try
> http://packages.debian.org/unstable/misc/iso-codes
>
> To use the textual domain, I copy from the README file of the package:
>
> ``Currently there are lists of languages and countries embedded in:
>
> - Gnome Libs
> - bootfloppies / PGI
> - KDE
> - Gnumeric
> - Gnucash
> - ...''
>
> ``So the plan is then to be able to use
> dgettext("iso-639", language_name)
> to get the correct translations.''
>
> In addition, it recommends to contact the maintainer of the iso-codes
> package when you are considering to make an implementation, as the
> current format is in flux.
>
> Kexchange (http://www.favorin.com/projects/kexchange/) does not make use
> of iso-codes but rather translates again the currency names.
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
RESOLVED: Re: gweather Locations.xml in GNOME 2.10, does it work for you?
ÎÏÎÏ 24/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÎÏÏÎ ÎÎÎ ÏÏÎ 02:59, Î/Î Simos Xenitellis ÎÎÏÎÏÎ: > ÎÏÎÏ 24/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÎÏÏÎ ÎÎÎ ÏÏÎ 02:25, Î/Î > Vincent van Adrighem > ÎÎÏÎÏÎ: > > Op do, 24-03-2005 te 02:15 +, schreef Simos Xenitellis: > > > For the case of the airport/city/location names, they are stored in > > > /usr/share/gnome-applets/gweather/Locations.xml > > > I verified that the applet reads succesfully the file (using "strace"), > > > however it only shows the names of the countries in Greek but not the > > > locations or cities. > > > > > > Could you please verify specifically that when you look for "Athens" > > > (Europe/Greece/"Athens"), it shows it indeed in Danish, that is, as > > > "Athen" (without ending "s")? > > > > > > Simos Xenitellis > > > > > > p.s. > > > Thanks Arangel for the "me too". > > Well, I should have double checked before I opened my big mouth. :) > > > > It looks like the cities don't get translated. Athens shows up as > > "Athens", but should show up as "Athene" in Dutch (nl). > > > > So, my works-for-meâ is hereby changed to a me-tooâ. > > Ack. > > Raphael verified for Portuguese and I also checked with Spanish. > > I submitted a bug report at > http://bugzilla.gnome.org/show_bug.cgi?id=171444 This bug report has just been resolved. gnome-applets 2.10.1 contains the fix, therefore if your distribution contains this version (as opposed to 2.10.0), you will be able to see the city/aiport names in the local language (if they are translated). gnome-applets 2.10.1 has gone to Ubuntu Linux Hoary Release Candidate, meaning that it will make it to the final release in a few days. When you showcase localised GNOME to end-users, it's good eye-candy to view the weather conditions of the local city, in the local language. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Difficult strings
Keld Jørn Simonsen wrote: On Thu, Jun 09, 2005 at 04:30:31PM +0800, Funda Wang wrote: Clytie> WAN cards: Wide Area Network cards, Funda, AFAIK. Thanks. I was thing of it at first. But what is that? Are the LAN cards really different from the WAN cards? I've never heard of such a device named as "WAN cards", besides ADSL modem, Cable modem, ATM adaptor, etc. could be a card that is cabable of doing the 802.16a wireless wan protocol, that has a range of about 50 km instead of 11g's 300 m. To me this is an interesting technology. Try googling with "WAN card" and you will get quite some results. WAN is for Wide Area Network. Typically WAN cards are not consumer electronics, so they are not that high profile. For example, you would need a WAN card for a T1/E1 connection. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Expended military alphabet
Στις 20/Ιούν/2005, ημέρα Δευτέρα και ώρα 15:09, ο/η Alexandra Telescu έγραψε: > Hi, > > I want to have in gnopernicus all characters translated in every > language. This is used to spell the text when in military mode. At this > time gnopernicus uses a 'translation' table only for the base roman > alphabet and few other special characters. > > The big challenge here is how to do this for _all_ characters (shown by > charmap) and to > use as less resources as possible. Having all marked for translation > will make the .po files really huge. > > I checked how charmap deals with this problem, and I discovered that > the "descriptions" of characters are not translated, at least for > Japanese and Romanian. Does anybody have an idea how to deal with this > situation? > > This problem is subject of gnopernicus bug: > http://bugzilla.gnome.org/show_bug.cgi?id=307566 I think this is a technical challenge; how to add a variable-length list of words to a PO file. For example, for the Greek language there are 24 letters, other alphabets have different sets of letters. A hack to do this? msgid "alphabet" msgstr "ΑΒΓΔΕΖΗΘΙΚΛ.." msgid "MilAlphabet_1" msgid "ΑΛΦΑ" msgid "MilAlphabet_2" msgid "ΒΗΤΑ" msgid "MilAlphabet_3" msgid "ΓΑΜΜΑ" msgid "MilAlphabet_4" msgid "ΔΕΛΤΑ" . There will be MilAlphabet_x, x up to around 50, if that captures to biggest alphabet. How is the military alphabet with CJK or Indic scripts; The program would easily associate letters to their representation in the local language. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Open Language Tools (translation tools by Sun) released!
Hi All, I just noticed that the Open Language Tools by Sun Microsystems have just been released as open-source software (CDDL license). Full comprehensive information at https://open-language-tools.dev.java.net/ They support gettext PO, DocBook XML(?), OpenOffice Writer and many other formats. It would be good to evaluate these tools and see how they can fit in the localisation processes of GNOME. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: rosetta
Jon Dufresne wrote: Hello, I am curious what connection the translation project has with the rosetta tool ubuntu uses, if any. I am not a big translator but I would like to contribute. I was poking around the ubuntu rosetta site and it seems really hand for quick translation and would lower the barrier for people to join. sorry if this has already been talked about. It has been discussed a few times indeed. Rosetta offers a translation service, you provide them with the .po files and you translate online. You cannot get the source code and setup your own Rosetta server. Another option is Pootle (http://pootle.wordforge.org/) which offers a translation service in addition to offering the source code. Pootle is actively developed (http://lists.sourceforge.net/lists/listinfo/translate-pootle) and provides a good option when you want to have a responsive web service, as it can be setup on your LAN for a "translation marathon" or on a fast computer in your country. We (Greek GNOME translators) are currently about to finish testing our own Pootle server to translate GNOME and other programs. More on installing Pootle, see: http://translate.sourceforge.net/wiki/pootleadmin Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Greek Polytonic and GTK+ IM problems
I try to get GTK+ IM (native) to type Greek Polytonic and I have some
problems.
The way I do it is to add to
http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkimcontextsimple.c?view=markup
in the
static const guint16 gtk_compose_seqs[] {}
the following:
GDK_dead_horn,GDK_Greek_alpha,0, 0, 0,
0x1f00, GDK_dead_horn,GDK_Greek_epsilon, 0, 0,
0, 0x1f10,
GDK_Multi_key,GDK_greater,GDK_Greek_alpha,
0, 0, 0x1f00,
GDK_Multi_key,GDK_greater,GDK_Greek_epsilon,
0, 0, 0x1f10
(The above are an example to allow typing just two letters: ἀ and ἐ).
I compile gtk+ 2.7.0 (cvs), install, test but I do not get the above
characters.
Any hints on what to do to get this working?
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Free/Open Source Software Guide to Localization Published
Hi All, I forward the announcement of a Localisation Guide by IOSN (http://www.iosn.net/). It's available from http://www.iosn.net/l10n/localization-guide/ released under the Creative Commons Attribution 2.0 license (http://creativecommons.org/licenses/by/2.0/). It complements the Localisation Primer released in June: http://www.iosn.net/l10n/foss-localization-primer/ <http://www.iosn.net/l10n/foss-localization-primer/foss-localization-primer.pdf> released under the Creative Commons Attribution 2.0 license (http://creativecommons.org/licenses/by/2.0/). The Localisation Guide goes in depth to most aspects of localisation and could be considered as essential reading :). Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Unannonced team de_BY or mistake?
Roozbeh Pournader wrote: On Sun, 2005-06-26 at 17:10 +0200, Christian Rose wrote: Things are changing... ;-) IS0 639-3 now has "bar" for Bavarian: http://www.sil.org/iso639-3/documentation.asp?code=bar Granted, ISO 639-3 is not an official ISO standard yet, it only has the status of "Draft International Standard" so far, but should anyone want to translate into Bavarian, then please use that code instead of inventing your own standard. Sorry for the late reply, but I consider using "bar" very dangerous. ISO 639-3 should not be used in GNU-related localization, since its model is not appropriate for localization work. There is also something else: There is no promise the code "bar" won't be used by ISO 639-2 for another language later. What alternative answer do you propose for the question: "We really want to localise, what language code shall we use?". I am not comfortable with "Sorry mate, no official language code yet, so no localisation". If an entry resides in ISO 639-3, it means that there are good hints that the official name will be just that. If it does not get to be official, then bad luck, we have to do a bit more work to clear up. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Query on generation of mo files
Paras pradhan wrote: hi all, Got a question on naming of mo files to be generated from po files of gnome 2.10 and newer. I will take an example of gnomemeeting. At the l10n-status site (http://l10n-status.gnome.org/gnome-2.10/PO/gnomemeeting.gnome-2-10.ne.po), the name of gnomemeeting po file is gnomemeeting.gnome-2-10.ne.po. now if i want to generate the mo file, what should the mo file be named. is it gnomemeeting.gnome-2-10.mo or gnomemeeting.gnome-.mo or any other..? how do i decide the names of the mo files?. It depends on what you want to do, though in most cases it is gnomemeeting.mo If you are compiling from source or CVS, the Makefile will setup the names accordingly and place the files with the correct names under the /usr/share/locale/ne/LC_MESSAGES/ (or /usr/local/share/locale/ne/LC_MESSAGES/ directory). The same Makefile instructs the binary gnomemeeting of what to look to find the .mo file. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Query on generation of mo files
[I did not click on "reply to all" for this reply, so I am sending to
list for reference].
I think I understand. Your issue is with packages that do not have
nepali .mo translations,
so you cannot overwrite the exist .mo file and be sure it works.
A very non-technical way to find out the exact name of the .mo file is
to see how existing
.mo files from other languages look like. For example, see Spanish
("es") or German ("de") in their
respective directories. It would be exactly the same filename.
Alternatively, does "apt-get" allow you to view the files included in
package?
For RPM you type "rpm -ql gnomemeeting" and you can see the contained
filenames.
A bit more technical way to identify the name would be to use "strace".
"strace" allows you to spy
on the system calls an application is making, so in this case you can
vividly see what .mo file an application
is trying to open.
First verify that the "strace" package is installed.
Then, run "strace -o output.txt gnomemeeting". Subsequently exit
gnomemeeting and run "grep '^open' output.txt".
This will show you the full list of files that gnome-meeting tries to
open, including the .mo filename.
Simos Xenitellis wrote:
Paras pradhan wrote:
hi all,
Got a question on naming of mo files to be generated from po files of
gnome 2.10 and newer.
I will take an example of gnomemeeting.
At the l10n-status site
(http://l10n-status.gnome.org/gnome-2.10/PO/gnomemeeting.gnome-2-10.ne.po),
the name of gnomemeeting po file is gnomemeeting.gnome-2-10.ne.po. now
if i want to generate the mo file, what should the mo file be named.
is it gnomemeeting.gnome-2-10.mo or gnomemeeting.gnome-.mo or any
other..?
how do i decide the names of the mo files?.
It depends on what you want to do, though in most cases it is
gnomemeeting.mo
If you are compiling from source or CVS, the Makefile will setup the
names accordingly and place the files with
the correct names under the /usr/share/locale/ne/LC_MESSAGES/ (or
/usr/local/share/locale/ne/LC_MESSAGES/ directory).
The same Makefile instructs the binary gnomemeeting of what to look to
find the .mo file.
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Query on generation of mo files
Paras pradhan wrote:
Ok using strace i found the following line by grepping..
--
open("/usr/share/locale/ne/LC_MESSAGES/gnomemeeting.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
--
which means this the good way i can get the names.. i will check them..
but i can't use strace whoese binary executable is not known
like: libgtop and others...
i don;t know which binary application is using libgtop.
How about checking
/usr/share/locale/es/LC_MESSAGES/
The Spanish team (among others) have already translated the full of
GNOME 2.10 so there exist
a .mo file for every single translation domain.
In Debian, when you install a GNOME application, doesn't it install the
.mo files of all other languages as well?
I think this feature has not been fixed yet.. :) so it is very easy to
find the filenames.
For example,
/usr/share/locale/es/LC_MESSAGES/libgtop.mo
implies that there should be a
/usr/share/locale/ne/LC_MESSAGES/libgtop.mo
Simos
On 7/20/05, Simos Xenitellis <[EMAIL PROTECTED]> wrote:
[I did not click on "reply to all" for this reply, so I am sending to
list for reference].
I think I understand. Your issue is with packages that do not have
nepali .mo translations,
so you cannot overwrite the exist .mo file and be sure it works.
A very non-technical way to find out the exact name of the .mo file is
to see how existing
.mo files from other languages look like. For example, see Spanish
("es") or German ("de") in their
respective directories. It would be exactly the same filename.
Alternatively, does "apt-get" allow you to view the files included in
package?
For RPM you type "rpm -ql gnomemeeting" and you can see the contained
filenames.
A bit more technical way to identify the name would be to use "strace".
"strace" allows you to spy
on the system calls an application is making, so in this case you can
vividly see what .mo file an application
is trying to open.
First verify that the "strace" package is installed.
Then, run "strace -o output.txt gnomemeeting". Subsequently exit
gnomemeeting and run "grep '^open' output.txt".
This will show you the full list of files that gnome-meeting tries to
open, including the .mo filename.
Simos Xenitellis wrote:
Paras pradhan wrote:
hi all,
Got a question on naming of mo files to be generated from po files of
gnome 2.10 and newer.
I will take an example of gnomemeeting.
At the l10n-status site
(http://l10n-status.gnome.org/gnome-2.10/PO/gnomemeeting.gnome-2-10.ne.po),
the name of gnomemeeting po file is gnomemeeting.gnome-2-10.ne.po. now
if i want to generate the mo file, what should the mo file be named.
is it gnomemeeting.gnome-2-10.mo or gnomemeeting.gnome-.mo or any
other..?
how do i decide the names of the mo files?.
It depends on what you want to do, though in most cases it is
gnomemeeting.mo
If you are compiling from source or CVS, the Makefile will setup the
names accordingly and place the files with
the correct names under the /usr/share/locale/ne/LC_MESSAGES/ (or
/usr/local/share/locale/ne/LC_MESSAGES/ directory).
The same Makefile instructs the binary gnomemeeting of what to look to
find the .mo file.
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Language switcher applet
Yavor Doganov wrote: On Thu, 21 Jul 2005 11:46:50 -0400, Germán Poó Caamaño wrote: In previous versions of GNOME it was possible to run a application (o create a launcher) as "LANG=es_US fo". However it was disabled around 2.2 o 2.0 (I guess to avoid any security issue as LD_PRELOAD or so). LANGUAGE=es foo Provided that you have the locale generated and the .mo files in place. This change from LANG to LANGUAGE (actually LANGUAGE takes precedence over LANG) cost me some evenings trying to figure out what's going on. Is this a GNOME feature or a distro issue? First found this new behaviour happening with Ubuntu Linux (Warty). Simos Greek Team http://www.gnome.gr/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Language switcher applet
Germán Poó Caamaño wrote: Le jeudi 21 juillet 2005 à 22:23 +0700, Ross Golder a écrit : I now use GNOME from day-to-day in my secondary language (Thai). I've found it has helped me practice reading/typing Thaiscript (a non-Roman alphabet) and is improving my Thai vocabulary. However, from time-to-time I come across a translated error message (in Thai) that I don't understand (yet!). Wouldn't it be great if I could switch the displayed language of all the GNOME applications on the screen with a language switcher applet, as easily as you can switch the keyboard layout between US and Thai (and British when I need a pound sign!). Not only would it let me get on quicker, but it would also help me improve my language skills, as I could spend a moment each time I get stuck flicking between the two languages and learn the words and the meaning of the phrases without having to resort to the dictionary :) I can think of tons of cases where this feature would be useful and it would be yet another cool feature that all the other desktops don't have (yet, afaik). So, I'm just wondering if it can be done and what would be involved. I can comment another case. In my desktop on my job I use French, as the same plan as you (my native language is Spanish). However, when I run synaptic (the software to update/upgrade my Debian/Ubuntu machine), but when I need to answer a dialog, I'd like to see the dialog in English (because I could break my machine if I misundertood a dialog). I would recommend to first search GNOME Bugzilla and if not found, make a bugzilla report on this, as an RFE (Request For Enhancement). I remember this being discussed in the list at least for a couple of times. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: cvs-po-commits-list *still broken*
Terance Edward Sola wrote: man, 25,.07.2005 kl. 21.22 +0700, skrev Ross Golder: On จ., 2005-07-25 at 12:21 +0300, Alexander Shopov wrote: Hi guys, cvs-po-commits-list continues to be broken. Check here: http://mail.gnome.org/archives/cvs-po-commits-list/2005-July/date.html Who do I have to contact about this? Best regards: al_shopov Ah, I see :( I set the list up originally, so I guess it's up to me to investigate. Unfortunately, I don't know off the top of my head what's causing it. I'll try to look into it when I get a moment. Thanks for pointing it out. -- Ross Could you update this post if/when it is fixed? As of now I have to subscribe to cvs-commits-list and filter it for the .po files I care about. Slightly overkill one might say :-) You may find helpful for now the RSS feeds by http://cia.navi.cx/ For example, http://cia.navi.cx/stats/author/al_shopov (replace last item with your username on GNOME CVS). These RSS feeds appear not to be affected. Simos Xenitellis Greek Localisation Team ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: msgfmt?
Ross Golder wrote: On อ., 2005-08-09 at 16:44 +0930, Clytie Siddall wrote: Hi guys :) I submitted an updated file today, and fortunately the commit check caught a variable which hadn't been changed. But my msgfmt check turned up clean. I find this very puzzling, since the variable was definitely wrong. Not sure if it's the best advice, but I did this for a load of gtranslator po files recently (changed 'translator_credits' to 'translator-credits' in all files with sed), and found a couple of them would no longer commit (due to new msgfmt checks). I fixed those cases where I could and simply commented out the ones that I couldn't (only a handful of cases). Hopefully, next time the translators looks over those files they'll get fixed up properly. Grepping the .po files from GNOME 2.12 today (now) shows that the following remain to be fixed: bug-buddy.HEAD.el.po:msgid "translator_credits-PLEASE_ADD_YOURSELF_HERE" dasher.gnome-2-12.el.po:msgid "translator_credits" gconf-editor.HEAD.el.po:msgid "translator_credits" gnome-applets.HEAD.el.po:msgid "translator_credits" gnomemeeting.HEAD.el.po:msgid "translator_credits" gnome-netstatus.HEAD.el.po:msgid "translator_credits" gnome-nettool.HEAD.el.po:msgid "translator_credits" gucharmap.HEAD.el.po:msgid "translator_credits" Simos Xenitellis http://simos.info/blog/ I'm using: msgfmt -cv and normally that catches all the usual errors, including disparate printfs. What version of gettext are you using? I just checked, the version of gettext running on container for the commit check is 0.11.4. I didn't realise it was that ancient! I just tried to rebuild a more recent one (from FC4's 0.14.3 SRPM), but it's not playing nicely with the older auto* environment on the gnome.org servers (and I don't fancy upgrading all that too just to rebuild a gettext RPM!). CCing infrastructure: Consider this a 'todo' item to upgrade gettext on container. Or, arrange to get the machines upgraded to RHEL4 (or anything more up-to-date than bloody RHEL3!!!). -- Ross Can someone help me sort this out, please? I don't want to submit incorrect files. :( ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Splitting gnome-games into domains
Tino Meinen wrote: On ma, 2005-08-08 at 15:33 +0200, Danilo Šegan wrote: Today at 14:40, Tino Meinen wrote: If gnome-games is split up, will it not mean we would have to translate: msgid "quit" and other common messages for every single game? No if it's a Gtk+ stock item, or if you're using a translation memory (which you should, really). I know, I'm using my brain as translation memmory right now, but luckily it's pretty stable at present. gnome-games doesn't always use gtk+stock items ? for example: #. not translated on purpose #: ../aisleriot/menu.c:205 ../blackjack/src/blackjack.cpp:311 #: ../glines/glines.c:1710 ../gnect/src/main.c:1133 ../gnibbles/main.c:602 #: ../gnobots2/menu.c:60 ../gnome-stones/main.c:1052 #: ../gnometris/tetris.cpp:132 ../gnomine/gnomine.c:759 #: ../gnotravex/gnotravex.c:178 ../gnotski/gnotski.c:631 #: ../gtali/gyahtzee.c:513 ../mahjongg/mahjongg.c:1257 ../same-gnome/ui.c:427 msgid "_Help" msgstr "" It would seem to me that splitting gnome-games into different domains is overkill when there is a problem with just two messages. Wouldn't adding a context to the offending messages be an easier way to solve this? Agreed. But is it really just two messages? Are there maybe others which we don't even know about? Perhaps, I don't know, but I'm guessing it wouldn't be all that many. I just had a quick look at the po file and there are only a handfull of messages that are being used in more than one game. And some of those don't need different contexts as well I believe. For instance: #: ../blackjack/src/blackjack.cpp:317 ../gnobots2/gnobots2.schemas.in.h:23 msgid "Show toolbar" msgstr "" or #: ../aisleriot/sol.c:412 ../glines/glines.c:1967 ../gnobots2/statusbar.c:65 #: ../gnome-stones/status.c:71 ../gnometris/scoreframe.cpp:58 #: ../gnomine/gnomine.c:441 msgid "Score:" msgstr "" I think it is best not to split gnome-games and go with the solution Alexander Shopov suggests for the few messages that have context-problems. I second that. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Screenshots for the documentation, a question
Hi All, I'ld like to ask a preference question when taking screenshots for the GNOME Documentation. When taking screenshots of the Clearlooks theme, GIMP does not do a good job regarding the top left and top right edges of the image. For example, http://www.isg.rhul.ac.uk/~simos/misc/gtk-colour-wheel.png You will notice that this area is black, as the theme has a rounded title bar. Therefore, it's good to retouch manually so that you get a result similar to http://www.isg.rhul.ac.uk/~simos/misc/gtk-colour-wheel-shadow.png My question is, as these screenshots go in documentation, meaning that the background is white, is it better to have this variation? http://www.isg.rhul.ac.uk/~simos/misc/gtk-colour-wheel-shadow-reduced.png It would be good to be uniform in our documentation. In addition, if adding shadows and retouching the screenshots is a lot of effort, I would like to suggest to localisers to add basic screenshots in the figures/ directory and have a few people working on them to get them look nice. What do you think? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
"Automatic" UI translations showing word translations along with original
Hi All, Suppose the resources to translate to a specific language are not there but there is a dictionary available. It's possible to autotranslate the user-interface words so that the text appears as Before: Press here After: Press(Pulse) here(aqui) Would that be useful? Well, Tim Foster (http://blogs.sun.com/roller/page/timf/20050816) tried it out, so have a look at the screenshot he created and post your comments! Try to think if there would be any application of this functionality. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Kazakh Language
Behdad Esfahbod wrote: On Mon, 29 Aug 2005, Danilo Šegan wrote: That's a downside to free software development: it gets implemented only if someone really needs it. :) Isn't it a benefit of it?! In a non-free software, it gets implemented only if thousands/millions of people really need it and are willing to pay for it. Just to be pedantic, in free software it gets implemented if there determined people to do it. There are languages with relatively small audience that have good levels of localisation only because specific people came around and did/do the job. And the total effort is much cheaper than what you would get if you contract someone for proprietary software. Back to the Kazakh language :) Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Kurdish - we give it a start
Baris Cicek wrote: On Tue, 2005-08-30 at 12:37 +0200, Erdal Ronahi wrote: Hi Clytie, hi everybody, thanks for the warm words. To translate software into Kurdish is a great challenge indeed. Although close to 40 Million people speak Kurdish, it could not develop well, because it has been forbidden in Turkey, where most Kurds live. Still it is not been taught at any state school - let alone university. So we have to create a wholly "new" computer terminology, which makes this task very difficult. I'm not aiming to start a political discussion in here, but just want to fix a misinformation. This is to say 'Kurdish' is not forbidden in Turkey. It's just Turkey only let broadcasting and education in Turkish, in past. That's not special to 'Kurdish' or any other language. After language revolution of Turkey in 1938 people forced to use only Turkish with new form. Of course that was obsolate in new century where everyone is talking/using modern Turkish. During EU process Turkish Gov. let any minority to use its language in education and broadcasting with government permission. And that's the case in any other EU country (maybe even with broader rights). Though using Kurdish computer programmes were never forbidden in Turkey. Thus blaming Turkey for poor Kurdish support is kind of vague. According to the Human Rights Watch (http://www.hrw.org/reports/1999/turkey/turkey993-08.htm), it appears that minority languages have been prohibited in Turkey. It appears that the Kurdish language has not been prohibited specifically (all minority languages suffered, including Greek), but rather the effect was worse on the Kurdish language as the population speaking it was much larger and there was no other country to develop it. I am not sure if the consistution and the practices have changed since 1999 (link?), though the long legacy might be hard to change. It appears that in neighbouring countries with Kurdish populations there have been similar situations. Therefore, the point that Erdal makes could be rephrased from "because it has been forbidden in Turkey" to "because it has been effectively prohibitited in Turkey until [date]" The other difficulties are, as you said, economical underdevelopment and little computer access. I am happy that the international free software community - and especially the GNOME supports all kinds of localization efforts. Because other players in the software market don't. I personally support every attemt to localize software for local market/usage. Kurdish is no exception. You can get support from our mailing list [EMAIL PROTECTED] And for sending Kurdish translations untill your cvs account will be ready, you can send your files to me and I can commit them to CVS. I think this help would be great for the new language support. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: "Automatic" UI translations showing word translations along with original
Tim Foster wrote: Hey all, Promise, this will be the last I'll write on this for a while - but people suggested I look at bi-gram, tri-gram and up to 5-gram distributions of words found in GNOME software messages. That is, given the input message : "This is a long sentence so there." We'd get the tri-grams : This is a is a long a long sentence long sentence so sentence so there - usually people mess about with this sort of thing when trying to build terminology lists, but I suspect my sample set is a bit small to be interesting. Regardless, I've got results at http://blogs.sun.com/roller/page/timf?entry=more_word_bagging I hope there is more to this work. I believe there should be some aid to the localisation process. I went through the initial wordlist, starting with the 1200 most common words, and removed those words that are either elemental (articles, connectict words, adverbs, untranslated words like FTP, etc). The resulting list has 1000 words and the file is available at http://www.isg.rhul.ac.uk/~simos/misc/gnome-2.10-words--reduced.sxc The first sheet is that by Tim, the second one is the reduced one. Some stats on the 1000 word list: - The most common term is "file", with 1200+ occurences. - The top five words are file image name color window - "right" and "left" have same number of occurences, good! (184) - In the list of 1000 most popular words, the last one is "suspend", with 18 occurences. - The full list has 10.000 words in a total of 34.000 messages in GNOME 2.12. Hope this helps, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: massive string freeze breakage
Jordi Mallach wrote: On Tue, Aug 30, 2005 at 05:39:14PM +0200, Danilo Šegan wrote: I don't remember approving them, and I didn't see any request either. So, by our standards, they are "unintended" :) Heh, alright. The race against 100% is getting fun lately. :) Yeah. Unfortunately, I've been a bit busy these days, so I wonder if you or someone else could come up with a proper report so we can bug gnopernicus developers to revert the change? I'm a bit busy right now to find out culprit commits, etc. If someone else wants to do it, please go ahead. FWIW, my file is now up to date, so I have little personal interest right now :P It looks it's Oana Serb, from BAUM Retec AG (http://www.baum.ro/), the creators of accesibility support in GNOME (under contract from Sun?). She closed a l10n bug report (http://bugzilla.gnome.org/show_bug.cgi?id=309039#c10) filed by Clytie and obviously did not notice the string freeze. We translated the new strings as well, so we do not mind if the changes are kept. We will top with Jordi on the next trans stats e-mail. :) Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translating the GNOME 2.12 release notes
Nikos Charonitakis wrote: 2005/8/31, Tino Meinen <[EMAIL PROTECTED]>: Op wo, 31-08-2005 te 01:58 +0300, schreef Nikos Charonitakis: i ve noticed that stats on web are different from actual file in cvs. for Greek file is: cvs 91 translated messages, 46 fuzzy translations, 96 untranslated messages. web 119 translated messages, 17 fuzzy translations, 97 untranslated messages. CVS is updated continuously, the web only once or twice a day, so there will always be differences between the two Greek file in CVS is the same for 2+ days but stats are always different on web Could it be an issue with the version of intl-tool or the po<->xml conversion tool? Simos Also, press release will be translated the same way as release notes? i didnt see any pot file. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: massive string freeze breakage
Danilo Šegan wrote: Yesterday at 2:09, Jordi Mallach wrote: Does anyone know if the new strings in gnopernicus were intended or approved? I don't remember approving them, and I didn't see any request either. So, by our standards, they are "unintended" :) The race against 100% is getting fun lately. :) Yeah. Unfortunately, I've been a bit busy these days, so I wonder if you or someone else could come up with a proper report so we can bug gnopernicus developers to revert the change? See http://bugzilla.gnome.org/show_bug.cgi?id=309039 especially last two comments. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Release notes, Greek bug (Docbook XML related)
Hi All, There is a bug in the DocBook XML stylesheets for the Greek language which makes pages like http://www.gnome.org/start/2.12/notes/el/rnusers.html show the line (Caption, in this case) Ó÷Þìá 1. Attractive, friendly, simple: the new default theme. instead of Σχήμα 1. Attractive, friendly, simple: the new default theme. This is caused due to an issue with encodings in file /usr/share/xml/docbook/stylesheet/nwalsh/common/el.xml of the server that generates the Release Notes. An updated/fixed version of the file has been posted and accepted last April at http://sourceforge.net/tracker/index.php?func=detail&aid=1168778&group_id=21935&atid=373747 though it may take a bit to appear in distributions. Therefore, could you please replace /usr/share/xml/docbook/stylesheet/nwalsh/common/el.xml on the server that generates the Release Notes, to the file mentioned at http://sourceforge.net/tracker/index.php?func=detail&aid=1168778&group_id=21935&atid=373747 so that http://www.gnome.org/start/2.12/notes/el/ appears well in Greek? Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Release notes, Greek bug (Docbook XML related)
Στις 04/Σεπ/2005, ημέρα Κυριακή και ώρα 21:30, ο/η Danilo Šegan έγραψε: > Hi Simos, > > Today at 21:02, Simos Xenitellis wrote: > > ... > > though it may take a bit to appear in distributions. > > Do you really want to know what distribution is being used on > window.gnome.org (server where everything is generated)? I don't > think you do, but anyway, it's RHEL 3 (released in September 2003[1])! > > [1]http://www.redhat.com/software/rhel/3features/ > > It may take a bit more than "a bit" to appear in that distribution, > y'a know :) > > FWIW, Serbian translations show the English "Figure 1." title. > Anyway, we definitely want to port the stylesheets to use Shaun's > excellent l10n xsl stylesheets (as used in Yelp), but that's only 2.14 > material. > > Maybe you can see with web, marketing or sysadmin teams about fixing > this short-term for you, but I really think we should go with > everything Shaun is doing inside gnome-doc-utils in the future. Thanks for the update. I'll bug http://sysadmin.gnome.org/contact.html and specifically the gnome-infrastructure mailing list, so that this specific file gets replaced. If you have an sr.xml, have it ready in case it gets done. Indeed, this is a short-term fix. My request is at http://mail.gnome.org/archives/gnome-infrastructure/2005-September/thread.html Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Release Notes screenshots
Στις 06/Σεπ/2005, ημέρα Τρίτη και ώρα 16:48, ο/η Shaun McCance έγραψε: > On Tue, 2005-09-06 at 17:29 +0200, Murray Cumming wrote: > > > what about some localized screenshots that are missing? > > > C screenshots will take their place? > > > > Only if you copy them yourself. You should do that if you are missing some > > screenshots. It's not the end of the world if some of your screenshots are > > English. > > You guys are only using the bits of g-d-u that pertain to setting > up and managing the translations, aren't you? For installable > documentation, g-d-u's install rules do automatically install C > figures for any missing figures in a locale. It would be really > nice to have a single, unified gnome-doc-utils-web.make or some > such that just magically gets stuff done. Automatically invoking the C/figures/ images is great. Talking about this, http://www.gnome.org/start/2.12/notes/en/ looks to be quite problematic as no screenshots are showing. The default release notes is http://www.gnome.org/start/2.12/notes/C/ You may have a look at it. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: pa translation is breaking the press release build
Vincent Untz wrote:
It really needs to be fixed since it blocks the entire website from
being updated (AFAIK).
if test -f "C/press_release.xml"; then d="../C/"; else d=".././C/"; fi; \
(cd pa/ && \
export [EMAIL PROTECTED]@/www.gnome.org/start/2.12/press_release; \
`which xml2po` -e -p pa.po ${d}press_release.xml > press_release.xml)
Traceback (most recent call last):
File "/usr/bin/xml2po", line 750, in ?
CurrentXmlMode.postProcessXmlTranslation(doc, translationlanguage, outtxt)
File "/usr/share/xml2po/docbook.py", line 181, in postProcessXmlTranslation
copy.newChild(None, "year", match.group(3))
File "/usr/lib/python2.4/site-packages/libxml2.py", line 3216, in newChild
ret = libxml2mod.xmlNewChild(self._o, ns__o, name, content)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3:
ordinal not in range(128)
make[1]: *** [pa/press_release.xml] Error 1
make[1]: Leaving directory
`/gnome/cvs/gnomeweb-wml/www.gnome.org/start/2.12/press_release/docbook'
make: *** [all-recursive] Error 1
It's the "translator-credits" message.
Currently the value for pa.po is:
msgid "translator-credits"
msgstr "ਅਮਨਪਰੀਤ ਸਿੰਘ ਬਰਾੜ ਆਲਮਵਾਲੀਆ <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
2004,2005"
Here, docbook.py does special processing, parsing the name, e-mail and
year. It breaks however, if there is some non-ascii characters.
I did not have the time to investigate this, I believe it's a bug in
docbook.py, that when parsing, it does not consider that there can be
UTF-8 characters in the name here.
The same problem happened for Greek and it was resolved by writing the
names in US-ASCII (ie, English).
The quick fix is to change the name from "ਅਮਨਪਰੀਤ ਸਿੰਘ ਬਰਾੜ ਆਲਮਵਾਲੀਆ" to
"Amanpreet Singh Alam".
Below are the header comments of pa.po:
# Amanpreet Singh Brar <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>, 2005.
# Amanpreet Singh Alam <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>, 2005.
Amanpreet, would that be ok?
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Release notes, Greek bug (Docbook XML related)
Danilo Šegan wrote: Hi Nikos, Today at 14:26, Nikos Charonitakis wrote: can we use the same for Greek release notes if changes in server cant be made in time? This will also have to be arranged with sysadmin team. There is really nothing we can do without privileged access to the machine. So, while you are at it, just have it fixed instead! Just to note that the gnome-infrastructure people were kind enough to fix it! Now http://www.gnome.org/start/2.12/notes/el/rnusers.html looks really cool! Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Release notes, some messages dont's appear in the final document
Hi, Some messages that exist in LL.po do not appear to make it at http://www.gnome.org/start/2.12/notes/ Specifically, A. msgid "translator-credits" Should they appear at http://www.gnome.org/start/2.12/notes/es/rncredits.html http://www.gnome.org/start/2.12/notes/el/rncredits.html http://www.gnome.org/start/2.12/notes/bg/rncredits.html B. rnthanks.xml does not appear to get built (no rnthanks.html) so messages such as #: /tmp/doc-l10n/cvs/release-notes.HEAD/C/rnthanks.xml:26(para) msgid "Shailesh Mittal for IPv6 support" do not appear in the final Release Notes. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Can't commit updated PO file: gtkhtml gnome-2-12
Hi, The command line is $ cvs -z3 commit -m "Updated Euskara translation" I think that adding the files you want to update in the command line causes the problem. CVS is smart to find by itself which files need sending to the server. Simos dooteo wrote: Hi, I'm still can't commit eu.po file to gtkhtml (gnome-2-12 branch) even that a few minutes ago I'd commit eu.po's for libgtop, zenity, etc... eu.po file is msgfmt perfectly, without errors. Any suggest? Thanks and best regards, dooteo On og., 2005-09-08 at 18:15 +0200, dooteo wrote: Hi, I've got some problems to commit gtkhtml updated translations to gnome-2-12 branch /mnt/gnome/gtkhtml-2.12/po$ cvs commit eu.po ChangeLog cvs server: sticky tag `gnome-2-12' for file `eu.po' is not a branch cvs server: sticky tag `gnome-2-12' for file `ChangeLog' is not a branch How can I commit them? I'm commiting updates files last days until now and there was no problem :) Thanks and best regards, Dooteo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: icons for languages
Roozbeh Pournader wrote: On Tue, 2005-09-13 at 16:01 +0200, Gudmund Areskoug wrote: I know, that's why I indicated "region", not "country". No matter what one thinks of e. g. Greater Kurdistan, it's hard to dispute there's currently a substantial group of people living and speaking Kurdish in a given geographic location. It's hard, but they still dispute it. Believe me, *some* maps of Greater Kurdistan that is supposed to where current Kurdish speakers live, include Azerbaijani-speaking areas, Lori-speaking areas, Persian- speaking areas, and Arabic-speaking areas. I don't know enough about the politics of Kurdish in Iraq and Turkey. That is only from my knowledge of Iran. In other words, yes, contrary to what you think, it is very very controversial to claim that a substantial group of people speaking in a certain region speak Kurdish. Danilo, would you please come to my aid? I guess you have a similar problem in the areas that made the former Yugoslavia. I suppose you refer to FYROM which oftentimes causes issues with Greece due to claims for affinity with ancient macedonia, either in terms of language or in terms of history. Indeed, it's a difficult problem to solve yourself. For one reason or another, it's common to delegate the task to international standards, and follow them to the letter. It would still cause grievances, though you can direct now to ISO. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Print Content (libgnomeprintui)
Reinout van Schouwen wrote: Hi, Could someone please clarify whether "Print" is a noun or a verb in the following string: #: ../libgnomeprintui/gnome-print-content-selector.c:133 msgid "Print Content" Hello, The following is a bit investigative, probably to be used in similar cases. Reading the comment line of the message, the specific source file is http://cvs.gnome.org/viewcvs/libgnomeprintui/libgnomeprintui/gnome-print-content-selector.c?view=markup Still, it is not conclusive as the "Print Content" functionality has been added very recently and there are not many hints in other files. Typical files to check for hints are 1. ChangeLog (recent addition, one terse entry for this functionality) http://cvs.gnome.org/viewcvs/libgnomeprintui/ChangeLog?rev=1.549&sortby=date&view=markup 2. doc/ (not updated to include this functionality) 3. po/LL.po (other language translations; check a couple of languages for hint) 4. contact the developer (from ChangeLog): Lutz Mueller users.sourceforge.net> <mailto:[EMAIL PROTECTED]> 5. ".c" files come with ".h" files, so see http://cvs.gnome.org/viewcvs/libgnomeprintui/libgnomeprintui/gnome-print-content-selector.h?view=markup Still no conclusive info. From the limited information we collected above, if we put them together, we have "gnome-print-content-selector.h" A functionality to select content (text and perhaps images?) from a document and print only that. Still, it is more common (as in OOo) to see "Print Selection". In this extreme case, it would be good to contact the author, unless someone else already knows about this feature. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Starting Kirghiz translation
Timur Zhamakeev wrote:
Hi,
I am starting the Kirghiz (also knows as Kyrgyz) translation of GNOME.
I have already registered as the team leader for Kirghiz (ky), see
http://mail.gnome.org/archives/gnome-i18n/2004-March/thread.html#00318
Could you please add a section for Kirghiz translations at the statistic
pages,
http://l10n-status.gnome.org/gnome-2.14/index.html?
How can I commit my translations?
Should I have CVS access?
Hi Timur,
For the first few translations, it is common to send your translations
to someone who already has CVS access.
Therefore, feel free to send me your .po files to submit.
I have already added your first translation for "yelp".
You can view it at
http://cvs.gnome.org/viewcvs/yelp/po/ky.po
Could someone add Kirghiz ("ky") to the statistics page?
Thanks for joining the Localisation of GNOME,
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Starting Kirghiz translation
Timur Zhamakeev wrote:
On 10/26/05, Simos Xenitellis <[EMAIL PROTECTED]> wrote:
Timur Zhamakeev wrote:
Hi,
I am starting the Kirghiz (also knows as Kyrgyz) translation of GNOME.
I have already registered as the team leader for Kirghiz (ky), see
http://mail.gnome.org/archives/gnome-i18n/2004-March/thread.html#00318
Could you please add a section for Kirghiz translations at the statistic
pages,
http://l10n-status.gnome.org/gnome-2.14/index.html?
How can I commit my translations?
Should I have CVS access?
Hi Timur,
For the first few translations, it is common to send your translations
to someone who already has CVS access.
Therefore, feel free to send me your .po files to submit.
I have already added your first translation for "yelp".
You can view it at
http://cvs.gnome.org/viewcvs/yelp/po/ky.po
Could someone add Kirghiz ("ky") to the statistics page?
Thanks for joining the Localisation of GNOME,
Simos
Hi Simos!
The stat page for Kirghiz already added, but in
http://l10n-status.gnome.org/gnome-2.14/index.html
for Kirghiz language is displaying only language code (ky) and we
should add also language name as Kirghiz or Kyrgyz.
Please commit another Kirghiz po file, it goes as attach.
Done!
Available at http://cvs.gnome.org/viewcvs/bug-buddy/po/ky.po
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: question related to commiting in 2.12 and 2.14 branches
Asprayama N wrote: Hello, as I understand when I am doing cvs -z3 co packagename then I have po file from 2.14 branch. I edited it and commited, its now browsable at http://l10n-status.gnome.org/gnome-2.14/hy/ So, I have to questions. Howto checkout gnome 2.12 po files? Have a look at http://l10n-status.gnome.org/gnome-2.12/hy/desktop/index.html The "branch" column signifies the "version" of the package that is used in the specific GNOME version. For example, for gnome-desktop, the branch is "gnome-2-12", therefore, to check it out you need to add "-r gnome-2-12" to the cvs checkout command. More on how to specify the branch of a software package is available at http://developer.gnome.org/tools/cvs.html You will notice that for GNOME 2.14 (http://l10n-status.gnome.org/gnome-2.14/hy/desktop/index.html) the branch is marked as "HEAD" which means that you do not have to specify a particular branch in the cvs command. And another, when I edited many lines in file from 2.14 branch should I edit same lines in 2.12? Is there some program that can change 2.12 po file so I do not need edit it line by line again? I am afraid that in 2.14 there are new lines which diesn't exist in 2.12 I noticed that you are starting the the Armenian translation. If you plan to complete the Armenian GNOME translations in the following 4-6 months (or longer), I would recommend to focus only on version 2.14. It will be substantially more work to translate at the same time both targets. If you have a very special reason to work on 2.12 as well, there are command line utilities as part of the gettext package that can allow you to merge/update PO files. For more on this, see http://www.gnu.org/software/gettext/manual/html_chapter/gettext_toc.html and the section on updating PO files. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Starting Kirghiz translation
Timur Zhamakeev wrote:
2005/10/27, Simos Xenitellis <[EMAIL PROTECTED]>:
Timur Zhamakeev wrote:
On 10/26/05, Simos Xenitellis <[EMAIL PROTECTED]> wrote:
Timur Zhamakeev wrote:
Hi,
I am starting the Kirghiz (also knows as Kyrgyz) translation of GNOME.
I have already registered as the team leader for Kirghiz (ky), see
http://mail.gnome.org/archives/gnome-i18n/2004-March/thread.html#00318
Could you please add a section for Kirghiz translations at the statistic
pages,
http://l10n-status.gnome.org/gnome-2.14/index.html?
How can I commit my translations?
Should I have CVS access?
Hi Timur,
For the first few translations, it is common to send your translations
to someone who already has CVS access.
Therefore, feel free to send me your .po files to submit.
I have already added your first translation for "yelp".
You can view it at
http://cvs.gnome.org/viewcvs/yelp/po/ky.po
Could someone add Kirghiz ("ky") to the statistics page?
Thanks for joining the Localisation of GNOME,
Simos
Hi Simos!
The stat page for Kirghiz already added, but in
http://l10n-status.gnome.org/gnome-2.14/index.html
for Kirghiz language is displaying only language code (ky) and we
should add also language name as Kirghiz or Kyrgyz.
Please commit another Kirghiz po file, it goes as attach.
Done!
Available at http://cvs.gnome.org/viewcvs/bug-buddy/po/ky.po
Simos
Hi Simos!
I'm sending you another Gnome Kyrgyz translation. Please commit it.
Done Timur.
See http://cvs.gnome.org/viewcvs/eel/po/ky.po
I also added "ky" to the supported languages for "eel" (as well as with
bug-buddy and yelp) in configure.in,
as shown at http://cvs.gnome.org/viewcvs/eel/configure.in?r1=1.209&r2=1.210
As shown in this page, the supported languages are listed in the long
line of language codes.
The list has to be alphabetic.
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
GNOME Localisation page (+award)
Hi All, As soon as I scribbled the page at http://uncyclopedia.org/wiki/GNOME_Localisation we got an award. I suppose marketing should work on localisation as well :) Simos p.s. Uncyclopedia, http://uncyclopedia.org/, is supposed to provide information in a funny way, as in parody. GNOME has a page as well, http://uncyclopedia.org/wiki/GNOME probably written by some KDE fan. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New Tajik Gnome Translation Team
Hi Roger,
Welcome to the GNOME Localisation Project!
Some tips additional to the welcome pack provided by Christian:
The "compilation" tools for PO files (msgfmt) are available in Linux by
default (most distributions).
There are also Win32 versions at
http://sourceforge.net/projects/gettext
There is a script you can use to grab all the PO files from
http://l10n-status.gnome.org/gnome-2.14/tg/
for easy distribution. However, note that these files change as GNOME develops.
Near the release time of GNOME 2.14 (around March 2006?) there will be a period
called "string freeze" where strings are guarranteed not to change,
so translators can work with peace of mind.
Therefore, you can plan to complete the current collection of PO files now
and in April work on the remaining messages.
Uncompressed the files are currently 3.6MB (just 435KB if compressed: ~2
minutes on 33Kbps).
To grab the PO/POT files, you can use the following commands:
1. wget -O desktop.html
http://l10n-status.gnome.org/gnome-2.14/tg/desktop/index.html
2. wget -O developer-libs.html
http://l10n-status.gnome.org/gnome-2.14/tg/developer-libs/index.html
These commands download the HTML pages from the statistics site. These
pages
contain links to the actual PO/POT files, they are updated a few times
per day.
3. grep '.pot' desktop.html developer-libs.html | awk -F\" '{print $6}'
| sort | uniq | awk '{printf "wget
http://l10n-status.gnome.org/gnome-2.14/tg/desktop/%s\n";, $1}' | sh
4. grep '.tg.po' desktop.html developer-libs.html | awk -F\" '{print
$6}' | sort | uniq | awk '{printf "wget
http://l10n-status.gnome.org/gnome-2.14/tg/desktop/%s\n";, $1}' | sh
These commands identify the translation files (either PO or POT) from
the statistics pages and create URLs to be used to download the
individual files.
If the process is difficult to use, feel free to ask me to send those
files in a compressed package.
All the best,
Simos
Christian Rose wrote:
On 11/11/05, Roger Kovacs <[EMAIL PROTECTED]> wrote:
Hi Everyone,
I subscribed to this list a short time ago to prepare for our
announcement to establish a Tajik Gnome translation team.
I will be the facilitator, providing a continuity for the various
volunteer translators throughout Tajikistan. This is the formal
request to establish the interface with the Gnome project.
Just a little background is appropriate - my name is Roger Kovacs, and
I have been involved with the Tajik LInux Translations for about 5 years
now. We have made great progress on Mandriva, KDE, and KOffice (maybe I
shouldn't have said that here). Now it is time to begin working Gnome
with a focus. The structure of our team is very unusual, but is proven
in previous projects, and is an effective method (considering the
circumstances.) The most unusual part is that I do not know much of
the Tajik language. One of the main issues in Tajikistan is that a
33Kb/s internet connection costs about 2 annual salaries per month of
service ($250US). A little bit expensive for the typical volunteer or
even a non-profit organization. So having a full time internet
connection in the USA, I e-mail .po files to translators (after doing a
rough 'automated' translation) who use KBabel to do the translations,
and when I get them back, I do a little quality control, verification,
and "compile" them into .mo files which I send back to the translator
for a final check. Upon the ok, I check them into the configuration
management system. At times, when there is funding, and an
organization called Youth Opportunities (www.tajikngo.org) will also
have configuration management system access and can provide
administration of the translation process. So my main role is to
provide continuity and allow for continuous progress via e-mail for the
volunteer translators. As progess is made in Tajikistan, a transition to
native translation coordinator will be accomplished. [FYI - typical
monthly salary in Tajikistan is about $10US, but I guess you figured
that out by now.]
Oh yes there are issues with this method, as it is very difficult to
share the translation database to develop standard terms, although I
try to do this twice a year. In addition, new releases are shipped to
Tajikistan on CD via DHL only a couple times per year, so they are
usually working behind the latest release. (Mail gets pilfered, so the
expense of DHL is necessary.) It is amazing how much the development
process is dependent on the internet, and we just take it for granted.
As an emerging nation, Tajikistan needs Linux and open source
applications due to the current economic conditions. The only computer
system in the Tajik language today is Linux. Linux is now being
accepted by the schools for education. Soon Tajikistan may be a nation
that will not need to migrate to Linux, but rather have evolved i
Re: gnome-vfs translation status
Ales Nyakhaychyk wrote: What's happened to gnome-vfs po module? I have commited be.po (HEAD) about four hours ago and now status page contains no translation for this module (only pot template). It is some bug in the scripts, it happens across all languages: http://l10n-status.gnome.org/gnome-2.14/es/developer-libs/index.html http://l10n-status.gnome.org/gnome-2.14/el/developer-libs/index.html http://l10n-status.gnome.org/gnome-2.14/fr/developer-libs/index.html However, you submission is there, see http://cvs.gnome.org/viewcvs/gnome-vfs/po/be.po Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: cvs-po-commit list broken yet again
Telsa Gwynne wrote: On Wed, Nov 23, 2005 at 12:01:36PM +0200 or thereabouts, Alexander Shopov wrote: Hi guys, cvs-po-commit mail list is seriously broken. It has been broken since 05 August 2005 at least. Yes. Does no one use this mail list? If the list has been broken for 2 months and no one complained - maybe it is time to just erase that list. I use it. I find it useful (when it works). It would be nice if the list is fixed, but I don't even know what is wrong with it. :( I think the commits list is also used for the CIA pages, such as http://cia.navi.cx/stats/author/telsa which are really useful. My understanding is that a bug report should be filed at Bugzilla to get the proper person to to fix it. There was a similar issue at FreeDesktop, with the fontconfig mailing list. I mailed Keith who is listed as list-admin at http://lists.freedesktop.org/mailman/listinfo/fontconfig but nothing happened. I also mailed the fontconfig list directly, still no response. Then, on IRC (xorg-devel) I was told to bugzilla it, and in a few hours it got resolved: https://bugzilla.freedesktop.org/show_bug.cgi?id=5109 Alexander, could you please make the bugzilla report? Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Thai Numbering in gnome-doc-utils
Theppitak Karoonboonyanan wrote: Hello, I'm going to translate gnome-doc-utils into Thai and find two required Thai numberings are missing. One is Thai alphabetical, and the other is Thai decimal digits. Thai alphabetical numbering is run with Thai consonants in the range: U+0E01 (THAI CHARACTER KO KAI) : U+0E2E (THAI CHARACTER HO NOKHUK) with three characters skipped, namely: - U+0E03 (THAI CHARACTER KHO KHUAT) - U+0E05 (THAI CHARACTER KHO KHON) - U+0E06 (THAI CHARACTER KHO RAKHANG) (i.e. the sequence is: U+0E01, U+0E02, U+0E04, U+0E07 .. U+0E2E) This is mainly used for numbering appendixes in Thai documents, and occasionally used in ordered lists. Numbering with Thai decimal digits is less used in general, but exists in most official or military documents. It just uses Thai digits in the range (U+0E50..U+0E50) for 0..9 respectively. I'm not sure about digits bahavior described by W3C's XSLT, nor what have been done in gnome-doc-utils, but let me mention a common mistake in some implementations: the assumed translation of digits. We would need an explicit way to specify whether to use Thai digits in numbering, rather than automatically translated. Thank you for your attention. Any comment would be appreciated. That's quite an interesting issue. I did not notice this information in the locale settings, nor in the documentation of gettext. Perhaps the linux-utf8 list is more appropriate for this? I am cc:ing there as well. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Thai Numbering in gnome-doc-utils
Shaun McCance wrote: On Tue, 2005-12-06 at 00:42 +, Simos Xenitellis wrote: Theppitak Karoonboonyanan wrote: Hello, I'm going to translate gnome-doc-utils into Thai and find two required Thai numberings are missing. One is Thai alphabetical, and the other is Thai decimal digits. Thai alphabetical numbering is run with Thai consonants in the range: U+0E01 (THAI CHARACTER KO KAI) : U+0E2E (THAI CHARACTER HO NOKHUK) with three characters skipped, namely: - U+0E03 (THAI CHARACTER KHO KHUAT) - U+0E05 (THAI CHARACTER KHO KHON) - U+0E06 (THAI CHARACTER KHO RAKHANG) (i.e. the sequence is: U+0E01, U+0E02, U+0E04, U+0E07 .. U+0E2E) This is mainly used for numbering appendixes in Thai documents, and occasionally used in ordered lists. Numbering with Thai decimal digits is less used in general, but exists in most official or military documents. It just uses Thai digits in the range (U+0E50..U+0E50) for 0..9 respectively. I'm not sure about digits bahavior described by W3C's XSLT, nor what have been done in gnome-doc-utils, but let me mention a common mistake in some implementations: the assumed translation of digits. We would need an explicit way to specify whether to use Thai digits in numbering, rather than automatically translated. Thank you for your attention. Any comment would be appreciated. That's quite an interesting issue. I did not notice this information in the locale settings, nor in the documentation of gettext. Perhaps the linux-utf8 list is more appropriate for this? I am cc:ing there as well. No, this issue is specific to gnome-doc-utils. The numbering systems have to be implemented in XSLT. We won't get any help from the rest of the system. This is all discussed in the extensive translator documentation in gnome-doc-utils. The translator documentation explicitly states which numbering systems are currently available, admits that they're insufficient, and asks translators to contact the developers about adding additional systems. Theppitak did that, and I've coded up support for five additional systems. Translators, if you want documentation to look right in your language, you need to tell me what's broken. Gnome 2.12.0 includes official support for 43 languages. I speak two of them, and only one of those really well. I've been looking at the numbering systems defined in CSS3 [1], and I'll probably converge towards those. But I need a clear understanding of who needs which numbering systems. At least one of the systems I've been asked to implement isn't on the CSS3 list, so I can't rely on W3C for everything. So that said, Simos, do you need Greek alphabetic numbering to be supported by gnome-doc-utils? We would love to have Greek numerals supported! However, the current locale support in CSS3 [1] appears to be quite suboptimal for Greek. The Greek alphabetic numbering follows the legacy of Ancient Greek which adds three letter-numbers [2]. Specifically, it introduces three letters (for 6, 90, 900) that shift the letters to the right: 6, 90, 900 are represented by ϛ (in modern Greek: στ), ϟ, ϡ According to [1], CSS3 does not take into account any of those characters and especially "στ". Therefore, there is the issue of correctness for 6, 7, 8, and so on. In addition, CSS3 is not good with the capitalisation (changing case) of Greek text, as there are specific rules that drop accents, and in some cases this depends on the context (based on the word). It appears that when CSS3 was being drafted, there was no feedback for Greek :( Therefore, it would be better for Greek not to use alphabetic numerals through CSS3 at this moment for issues of correctness. For the record, I sent an e-mail to this CSS3 working group in case it is possible to fix the missing letters. Thanks for bringing the issue to my attention. Simos [1] http://www.w3.org/TR/2002/WD-css3-lists-20021107/ [2] http://ptolemy.tlg.uci.edu/~opoudjis/unicode/numerals.html ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Thai Numbering in gnome-doc-utils
Shaun McCance wrote: On Tue, 2005-12-06 at 22:14 +, Simos Xenitellis wrote: Shaun McCance wrote: So that said, Simos, do you need Greek alphabetic numbering to be supported by gnome-doc-utils? We would love to have Greek numerals supported! However, the current locale support in CSS3 [1] appears to be quite suboptimal for Greek. The Greek alphabetic numbering follows the legacy of Ancient Greek which adds three letter-numbers [2]. Specifically, it introduces three letters (for 6, 90, 900) that shift the letters to the right: 6, 90, 900 are represented by ϛ (in modern Greek: στ), ϟ, ϡ According to [1], CSS3 does not take into account any of those characters and especially "στ". Therefore, there is the issue of correctness for 6, 7, 8, and so on. In addition, CSS3 is not good with the capitalisation (changing case) of Greek text, as there are specific rules that drop accents, and in some cases this depends on the context (based on the word). It appears that when CSS3 was being drafted, there was no feedback for Greek :( Therefore, it would be better for Greek not to use alphabetic numerals through CSS3 at this moment for issues of correctness. For the record, I sent an e-mail to this CSS3 working group in case it is possible to fix the missing letters. Thanks for bringing the issue to my attention. Well, gnome-doc-utils doesn't use CSS for most of its numbering. It uses calculators built into my XSLT code. It then formats these using either stock XSLT number formtters or code that I've written to handle a specific number system. The exception is actual ordered lists in DocBook. Currently, those do use CSS. There's also currently no way to specify which numbering system to use. It's a problem I'd like to solve, but I'm not sure how best to solve it. The primary reason I brought up CSS is that it appears to be a decent reference for numbering systems which I may need to implement in XSLT. But as we've seen, it's just not the best reference. (It is nonetheless good that you've emailed the working group for CSS3. CSS3 is still only a Working Draft, so they may be able to address the issues before finalizing it.) I actually got a reply a few minutes which is amazing. I will follow on on this, though I was told it might take quite some time before the standardisation. So here's the Wikipedia entry on Greek numerals: http://en.wikipedia.org/wiki/Greek_numerals Would you consider its definition of the Ionic numeral system to be correct? Would you prefer ϛ´ or στ´ be used for 6? Also, I don't think I've ever seen a document with a million sections, so I'm going to assume it's all right for me to stop trying after 999,999. Indeed, it is ok to go up to 999,999. For number 6 please use στ´ For 90 and 900, use the standard Ancient Greek symbols. In practical terms I believe those two numbers will not pop up very often. It is the most common in modern Greek, though there are some occurences of ϛ´. (Source: http://std.dkuug.dk/jtc1/sc2/wg2/docs/n1938.pdf) Do you need upper- and lowercase versions of this? Does weird stuff happen when I uppercase the numbers? Yes, we need upper-case for the alphabetic numbers. There are no exceptions when individual letters change case. The page also describes the acrophonic Attic numerals, which look considerably harder to implement. Do you need these in any document formatting stuff? Acrophonic Attic numerals are not used nowdays, so there is no need to implement. Many thanks for all, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Thai Numbering in gnome-doc-utils
Shaun McCance wrote: On Wed, 2005-12-07 at 00:09 +, Simos Xenitellis wrote: Shaun McCance wrote: So here's the Wikipedia entry on Greek numerals: http://en.wikipedia.org/wiki/Greek_numerals Would you consider its definition of the Ionic numeral system to be correct? Would you prefer ϛ´ or στ´ be used for 6? Also, I don't think I've ever seen a document with a million sections, so I'm going to assume it's all right for me to stop trying after 999,999. Indeed, it is ok to go up to 999,999. For number 6 please use στ´ For 90 and 900, use the standard Ancient Greek symbols. In practical terms I believe those two numbers will not pop up very often. It is the most common in modern Greek, though there are some occurences of ϛ´. (Source: http://std.dkuug.dk/jtc1/sc2/wg2/docs/n1938.pdf) Quick question: An inverted acute is placed before a character to make it larger by a factor of 1000. So δ´ is 4, but ,δ´ is 4000. All well and good. But then, we're using στ instead of ϛ for 6. There's no ambiguity there, because σ and τ are both digits in the 100s places, so they would never otherwise appear together. But now, what do we do when we want 6000? Is it jut ,στ´ or do we prefix both characters, as in ,σ,τ´? With the former, it's not clear if it means ,ϛ´ = 6000 or ,σ´ + τ´ = 200300. Do I prefix both characters? This is an interesting question. The issue here is that there is no single codepoing to represent στ. In addition to this, στ is a recent addition (last 80 years?) to Greek alphabetic numerals. Therefore, the general public would not recognise ϛ if it was used to represent 6. I expect the Greek alphabetic numerals will be most often used for numbered lists which should go up to 15-20. I am not sure if the numerals can be used for page numbers, and in this case they should typically go up to around 1000. Thus, please use ,ϛ´ for 6000. Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Gnopernicus 1.0 release
Oana Serb wrote: Hello, We have the pleasure to inform you that Gnopernicus 1.0 was released, . You can download the package at the following link: ftp://ftp.gnome.org/pub/GNOME/sources/gnopernicus/1.0/ or from GNOME CVS with the tag GNOPERNICUS_1_0_0 This is excellent news! Is there a list of What's new in this version of gnopernicus? I would like to pass it to the gnome-marketing mailing list so they can keep track of these additions. Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Mapping GNOME contributors from around the world!
Dear All, I started a community map at http://www.frappr.com/gnomedev for the people that contribute to the GNOME platform! Therefore, if you are involved in any aspect of GNOME development, please join in! For example, this includes people involved in coding, translating, marketing, porting, quality testing and last but not least documentation writing ;-) The OOo community has a head start, http://www.frappr.com/ooodev so give GNOMEDev your best: http://www.frappr.com/gnomedev Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Mapping GNOME contributors from around the world!
Арангел Ангов wrote: На пет, 2005-12-16 во 23:16 +, Simos Xenitellis напиша: Dear All, I started a community map at http://www.frappr.com/gnomedev for the people that contribute to the GNOME platform! Great idea Simos! The Balcan peninsula seems to be the most populated place on the map so far. :) Thanks Арангел! Without much publicity, the community now has over 25 members from around the world, with good representation from the I18n GNOME community. http://www.frappr.com/gnomedev Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Mapping GNOME contributors from around the world!
Ross Golder wrote: On อา., 2005-12-18 at 11:28 +0700, Theppitak Karoonboonyanan wrote: On 12/17/05, Luis Villa <[EMAIL PROTECTED]> wrote: You mean, like: http://live.gnome.org/GnomeWorldWide ? (linked to from planet.gnome.org) Isn't that for people who feed Planet GNOME? Sorry if I'm wrong. But that's my impression when seeing it there. It's anyone who adds their co-ordinates to the list further down on that same wiki page. A few points on GNOMEDev (http://www.frappr.com/gnomedev), a. It allows the contributor to immediatelly add themselves to the list, b. They can reposition themselves on the map easily as well. If you go on a trip (Guadec?), you can update your position while you are there. c. No need to find coordinates; you can set the city location, then fine-tune to the exact point on the map. d. You can zoom in/out on the map. e. Corollary: You can view individual contributors on congested parts of the map. For example, Europe looks congested now; zoom in and you see each individual user. f. You can add a thumbnail photo, full size photo as well as related photos. g. You can add shout-outs. Consider it as a mini-p.g.o. with easy access. I am not affiliated with the frappr service in any way. I feel that for marketing purposes (marketing-list AT gnome.org), it is important to 1. get end-users (as opposed to GNOMEDev) added to a similar map as well. Hmm, see http://www.frappr.com/gnomeusers replicating the effect of http://www.frappr.com/firefoxusers 2. make an effort to publicise GNOMEDev a bit more. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Mapping GNOME contributors from around the world!
Meelad Zakaria wrote: Hey Simos, I couldn't add Tehran as a city... can it be fixed? Hi Meelad, I just had a look and I can see that Tehran is included in the city list. 1. Log on to your personal home page, http://www.frappr.com/?a=myfrappr 2. Under the section My Profile, click on "Edit my Basic Profile" which takes you to http://www.frappr.com/?a=profile&type=basic 3. Under the section "My Location" choose Not in the US, and type "Tehran". Apparently they use AJAX so a list of cities will appear dynamically and you can choose Tehran from there. You can also use the map at that page to mark precisely your location if you wish to. Simos Cheers. On Sun, 2005-12-18 at 14:46 +, Simos Xenitellis wrote: Ross Golder wrote: On อา., 2005-12-18 at 11:28 +0700, Theppitak Karoonboonyanan wrote: On 12/17/05, Luis Villa <[EMAIL PROTECTED]> wrote: You mean, like: http://live.gnome.org/GnomeWorldWide ? (linked to from planet.gnome.org) Isn't that for people who feed Planet GNOME? Sorry if I'm wrong. But that's my impression when seeing it there. It's anyone who adds their co-ordinates to the list further down on that same wiki page. A few points on GNOMEDev (http://www.frappr.com/gnomedev), a. It allows the contributor to immediatelly add themselves to the list, b. They can reposition themselves on the map easily as well. If you go on a trip (Guadec?), you can update your position while you are there. c. No need to find coordinates; you can set the city location, then fine-tune to the exact point on the map. d. You can zoom in/out on the map. e. Corollary: You can view individual contributors on congested parts of the map. For example, Europe looks congested now; zoom in and you see each individual user. f. You can add a thumbnail photo, full size photo as well as related photos. g. You can add shout-outs. Consider it as a mini-p.g.o. with easy access. I am not affiliated with the frappr service in any way. I feel that for marketing purposes (marketing-list AT gnome.org), it is important to 1. get end-users (as opposed to GNOMEDev) added to a similar map as well. Hmm, see http://www.frappr.com/gnomeusers replicating the effect of http://www.frappr.com/firefoxusers 2. make an effort to publicise GNOMEDev a bit more. Simos ___ 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: xml2po (gnome-doc-utils)
Clytie Siddall wrote: Hello everybody :) I'm currently trying to convert a Docbook XML file to PO. I know I'm going to be translating more of these as time goes on, so I want to set up a quick procedure, at least until Pootle and/or other projects integrate po4a or similar. I am running Mac OSX 10.4.3, all updates current. I am not running Gnome. I hoped I could use xml2po from gnome-doc-utils. I downloaded the whole gnome-doc-utils directory. Then I tried converting the file: Pearl:~/Vietnamese/Main Projects/Gnome/gnome-doc-utils/xml2po clytie $ ./xml2po.py -o vi.po vi.xml Traceback (most recent call last): File "./xml2po.py", line 34, in ? import libxml2 ImportError: No module named libxml2 I have libxml2 in my $PATH. Hi Clytie, xml2po is a Python script, therefore for libxml2 support you need the "libxml2 Python binding" package. On Linux this is a package called "libxml2-python". Can you find such a package on OS/X? Have a look at http://xmlsoft.org/python.html for some additional help. Hope this helps, Simos Do I need to install the whole gnome-doc-utils? Or is there something else I need to do differently? Thanks for any help you can offer. :) from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN ___ 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: Mapping GNOME contributors from around the world!
Clytie Siddall wrote: On 28/12/2005, at 6:05 AM, Simos Xenitellis wrote: Hey Simos, I couldn't add Tehran as a city... can it be fixed? Hi Meelad, I just had a look and I can see that Tehran is included in the city list. That may not help. I was completely unable to choose Adelaide, South Australia (my closest large city) from the drop-down list. There wouldn't be a hand over that item, and when I tried to choose items further down the list which _did_ show a hand, the only thing that would occur was me being told the result was invalid/incorrect or whatever euphemism the page used as an error message. If I tried typing directly into the field, the text wouldn't appear, and the cursor would keep dropping to the next text field. I'm using OmniWeb 5.1.3b2 on Mac OSX 10.3.4, all updates current. I queried the page on omniweb-l, and other users tried it. They said they couldn't use the page at all. How are different browsers handling this page? That could be an issue with the so-called XMLRPC support in the browser. I could not establish whether OmniWeb supports XMLRPC. XMLRPC is a functionality found in Javascript. A webpage may contain Javascript code that dynamically loads content based on the input of the user. For example, see Google Suggest, at http://www.google.com/webhp?complete=1&hl=en Type a few letters, like "gno" and you will notice that Google will show typical results starting with "gno" and the number of results. Using XMLRPC, the Javascript code of the Frappr page loads dynamically the list of cities as you type. Depending on your connection, you may have to wait for a few moments for the XMLRPC request to complete. Even if you cannot type the city name, you can use the Google Maps minimap at the same page to set your location. Does the GoogleMap page work for you? You may also check with http://maps.google.com/ You can zoom in/out and also switch to Satellite view in case the map does not exist for your area yet. Hope it works, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: non-latin accelerator keys
Matthias Clasen wrote:
On 12/21/05, Abel Cheung <[EMAIL PROTECTED]> wrote:
Hi,
On 12/22/05, Matthias Clasen <[EMAIL PROTECTED]> wrote:
http://bugzilla.gnome.org/show_bug.cgi?id=323956
http://bugzilla.gnome.org/show_bug.cgi?id=104112
The first bug complains about the fact that the "(_F)" form in which
many CJK strings display the accelerator is not fully stripped out
when showing the string in a toolbar, and you end up with "(F)" in
the visible string.
I am considering to change gtk_toolbar_elide_underscores() to strip not
only lone _ characters, but also a sequence of the form " (_)" at the end of the string.
I have a number of questions here:
- Does this sound like a reasonable thing to do ? (the risk of
accidentally stripping something thats not an accelerator is
probably minimal, but not 0.
Indeed, there can be cases where a single CJK character is enclosed inside
parenthesis, and that's not uncommon; although when enclosed
character is a latin character it mostly means mnemonic key.
- Is the (_F) approach generally considered just a workaround for
the second bug, or are there languages where it is the
preferred/standard way to display accel keys ?
Well, it is preferred, since multiple keystrokes are needed to input
non-latin characters, and I doubt if anything like Alt- can
be entered at all. Hope anybody can enlighten me if this is
possible or not.
Ok, GTK+ 2.10 will strip out a suffix of the form "(_)"
in
addition to underlines, when displaying labels in toolbars. Please let me
know if you
notice any problems due to this.
I feel the end-user expects that shortcuts refer to the physical keys.
For example, in GTK+ apps as found in GNOME,
Alt-A (that's latin A)
Alt-Α (that's greek Α)
point to the same physical key, so menu entries like "_Αρχείο" works
just fine no matter which layout is active at the moment.
(Mozilla and OOo have trouble with this on XOrg and they work on it).
Regarding the solution of this, could GTK+
While loading the menu item strings
Extract shortkey letter (like Ά)
Search in gtk_compose_seqs[] (gtk+/gtk/gtkimcontextsimple.c) if
the character is there
('A is "GDK_dead_acute, GDK_Greek_ALPHA, 0, 0, 0, 0x0386, //*
GREEK CAPITAL LETTER ALPHA WITH TONOS */")
If shortkey letter is found, set the shortkey letter to "physical"
key (/GDK_Greek_ALPHA in this case)
For this to work efficiently, the structure gtk_compose_seqs[]
(gtk+/gtk/gtkimcontextsimple.c) should be duplicated with a sorted
version by the last entry (codepoint).
There is a pending issue of update gtk_compose_seqs[]
(gtk+/gtk/gtkimcontextsimple.c).
Are there languages/scripts not covered by this structure (for example,
not using GTK+ IM?).
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Problems with gnome-po-locations
Ilkka Tuohela wrote: Seems that gweather/Locations.xml.in contains now some invalid characters, or am I doing something wrong? Running intltool-update, I get 8 messages: Wide character in print at /usr/bin/intltool-extract line 810. After this, my UTF-8 file is no more UTF-8 and strings are garbled, fi.po: Non-ISO extended-ASCII English text Is there a problem with my intltool version (0.34.1-1) or do we just have invalid input data? It is a problem with intltool which has been fixed by http://bugzilla.gnome.org/show_bug.cgi?id=320721 It is possible your intltool package does not contain the fix. See if /usr/bin/intltool-extract has this simple change http://cvs.gnome.org/viewcvs/intltool/intltool-extract.in.in?r1=1.69&r2=1.70 The problem is caused by the parsing of the XML comments of intltool; normally inttool does not do any processing wrt text encodings, with the exception of comments in XML files where text is converted to the default Perl encoding of the script: iso-8859-1. Due to this, the following languages currently have invalid UTF8 PO files for gnome-applets/po-locations/ 1. cs 2. en_CA 3. it 4. ja 5. nl 6. sr 7. fr When you try to edit an invalid UTF-8 file, your text editor typically regards it as iso-8859-1. So if you save it, some characters get corrupted. One way to verify if your PO file is valid UTF-8 is to % iconv -f utf-8 -t utf-8 < el.po You will see the content of the file appear on screen. If there is a problem, the command will break with an error. As you see the file contents, you can easily pinpoint the error. These files appear not to have any content corrupted (like translated messages), so using the "iconv" test you can erase those problematic comments in order to fix. At least the Ukrainian file appears to have some corrupted entries, http://cvs.gnome.org/viewcvs/gnome-applets/po-locations/uk.po?view=markup See the end of the above page for some examples. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Translation problems with default location in Weather applet
Dear All, Several translations have problems with the default location in the Weather applet. The default location is used when you add the weather applet on your panel; it is the default location for your locale. Normally you put here the most common location, for example, the capital city of your country. For the last year the translator comments for these messages were misleading (they were not updated when gweather got a face lift). See the changes at http://cvs.gnome.org/viewcvs/gnome-applets/libgweather/gweather-gconf.c?r1=1.2&r2=1.3 The bug report is at http://bugzilla.gnome.org/show_bug.cgi?id=325327 and has been fixed on HEAD. The following languages have some problem with the code of the default location, "DEFAULT_CODE" bn gl gu hi hy ky mk ms ne pa sq ta te The code should be a 4 letters long, like "LGAV" for Athens, Greece. You would put here the capital city or any location with the biggest concetration of speakers of your language. See for available locations for your country http://cvs.gnome.org/viewcvs/gnome-applets/gweather/Locations.xml.in?view=markup (1.7MB HTML page) The following languages have some problem with the name of the default location, "DEFAULT_LOCATION": ar az bn fa gl gu he ky mk ms pa rw sq ta th vi zh_CN zh_TW The translation should be in your own language/script. Please do not put in English. msgfmt gets fooled with the underscore here and reports an error. The underscore in DEFAULT_LOCATION is not a shortcut. How can we say to gettext about this, as we do with "no-c-format" for the percentage sign? Some languages added the underscore in the translation here. There should be no underscore. DEFAULT_COORDINATES: Almost half of the languages got this one wrongly. The coordinates are like "37-56N 023-56E". In some cases, the location code has been placed here. Get the location coordinates from http://cvs.gnome.org/viewcvs/gnome-applets/gweather/Locations.xml.in?view=markup DEFAULT_ZONE: Only US/Canada have these zones, so in most cases this stays empty. To get the translation stats look ok, you can simply add a space in the translation. gweather will consider the zone as unknown and will not display something. If you translate to "DEFAULT_ZONE", gweather will use the default zone, in Pittsburgh. DEFAULT_RADAR: As with DEFAULT_ZONE. In some cases, DEFAULT_LOCATION has been translated verbatim resulting in a string that happens to be rather long. This can cause a buffer overflow, making the weather applet to crash as soon as you start it. If you get this crashing behaviour, it comes from the translation. If there are more weather locations for your country, you can make a bug report to add them to http://cvs.gnome.org/viewcvs/gnome-applets/gweather/Locations.xml.in?view=markup Cross reference the above URL with the page http://weather.noaa.gov/international.html Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation problems with default location in Weather applet
Ankitkumar Rameshchandra Patel wrote: Simos Xenitellis wrote: Dear All, Several translations have problems with the default location in the Weather applet. The default location is used when you add the weather applet on your panel; it is the default location for your locale. Normally you put here the most common location, for example, the capital city of your country. For the last year the translator comments for these messages were misleading (they were not updated when gweather got a face lift). See the changes at http://cvs.gnome.org/viewcvs/gnome-applets/libgweather/gweather-gconf.c?r1=1.2&r2=1.3 The bug report is at http://bugzilla.gnome.org/show_bug.cgi?id=325327 and has been fixed on HEAD. The following languages have some problem with the code of the default location, "DEFAULT_CODE" bn gl gu hi hy ky mk ms ne pa sq ta te The code should be a 4 letters long, like "LGAV" for Athens, Greece. You would put here the capital city or any location with the biggest concetration of speakers of your language. See for available locations for your country http://cvs.gnome.org/viewcvs/gnome-applets/gweather/Locations.xml.in?view=markup (1.7MB HTML page) The following languages have some problem with the name of the default location, "DEFAULT_LOCATION": ar az bn fa gl gu he ky mk ms pa rw sq ta th vi zh_CN zh_TW The translation should be in your own language/script. Please do not put in English. msgfmt gets fooled with the underscore here and reports an error. The underscore in DEFAULT_LOCATION is not a shortcut. How can we say to gettext about this, as we do with "no-c-format" for the percentage sign? Some languages added the underscore in the translation here. There should be no underscore. DEFAULT_COORDINATES: Almost half of the languages got this one wrongly. The coordinates are like "37-56N 023-56E". In some cases, the location code has been placed here. Get the location coordinates from http://cvs.gnome.org/viewcvs/gnome-applets/gweather/Locations.xml.in?view=markup DEFAULT_ZONE: Only US/Canada have these zones, so in most cases this stays empty. To get the translation stats look ok, you can simply add a space in the translation. gweather will consider the zone as unknown and will not display something. If you translate to "DEFAULT_ZONE", gweather will use the default zone, in Pittsburgh. DEFAULT_RADAR: As with DEFAULT_ZONE. In some cases, DEFAULT_LOCATION has been translated verbatim resulting in a string that happens to be rather long. This can cause a buffer overflow, making the weather applet to crash as soon as you start it. If you get this crashing behaviour, it comes from the translation. If there are more weather locations for your country, you can make a bug report to add them to http://cvs.gnome.org/viewcvs/gnome-applets/gweather/Locations.xml.in?view=markup Cross reference the above URL with the page http://weather.noaa.gov/international.html Simos "gu" (Gujarati-India) is fixed now ! Hi Ankit, Thanks for fixing this. I just found out that the brand new GNOME Bugzilla grants points to the bug contributors. Therefore, if you would like to get your first bugzilla point (see: http://bugzilla.gnome.org/page.cgi?id=points.html) feel free to "close" the GNOME Weather bug (change the status to FIXED and commit the changes), at http://bugzilla.gnome.org/show_bug.cgi?id=325393 GNOME Bugzilla has a hall of fame and thanks to these two localisation bugs, I just made it to the top 15 bug reporters :) http://bugzilla.gnome.org/reports/weekly-bug-summary.html To list all the reports on Gujarati, simply visit http://bugzilla.gnome.org/browse.cgi?product=l10n and click on the number next to your language (the number shows how many bug reports are pending for the language). When you click on the language name, it adds the name to the search box above and allows you to search for reports. However, there is a bug in Bugzilla for this (=ill-formed query), and I just file a new bug report http://bugzilla.gnome.org/show_bug.cgi?id=325454 [One more bug point for me! :) ] Therefore, I would suggest for all language teams to have a look at the bug reports for their respective language and start collecting bug points. If there are any problems with this procedure, please report back so we fix them. Happy New (Gregorian) Year 2006, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation problems with default location in Weather applet
Christian Rose wrote: On 12/31/05, Simos Xenitellis <[EMAIL PROTECTED]> wrote: Several translations have problems with the default location in the Weather applet. Simos, can you bug report these problems against the respective translation components in the "l10n" product in Bugzilla? That would probably make some translators more aware that there are problems in their translations, and as such it would be most helpful, I think. http://bugzilla.gnome.org/enter_bug.cgi?product=l10n I filed the reports to the respective teams as shown at http://bugzilla.gnome.org/buglist.cgi?product=l10n I am not sure if individual team members can "close" (mark as FIXED when done) those specific reports. It is nice to have those bug reports sorted out so there are no pending in the list. If there are issues on this, feel free to mail here. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translation problems with default location in Weather applet
Theppitak Karoonboonyanan wrote:
On 12/31/05, Simos Xenitellis <[EMAIL PROTECTED]> wrote:
The following languages have some problem with the name of the default
location, "DEFAULT_LOCATION":
ar
az
bn
fa
gl
gu
he
ky
mk
ms
pa
rw
sq
ta
th
vi
zh_CN
zh_TW
The translation should be in your own language/script. Please do not put
in English.
If so, shouldn't this block in gweather_gconf_get_location() also be changed
for parallelism?
--- 8< ---
name = gweather_gconf_get_string (ctx, "location4", NULL);
if (!name)
{
/* TRANSLATOR: Change this to the default location name,
* used when you first start the Weather Applet. This is
* the common localised name that corresponds to
* the location code (DEFAULT_CODE) you will put on the next message
* For example, for the Greek locale, we set this to "Athens", the
* capital city and we write it in Greek. It's important to translate
* this name.
*
* If you do not require a DEFAULT_LOCATION, set this to
* "DEFAULT_LOCATION".
*/
if (strcmp ("DEFAULT_LOCATION", _("DEFAULT_LOCATION")))
name = g_strdup (_("DEFAULT_LOCATION"));
else
name = g_strdup ("Pittsburgh"); /*** <-- It's in English here! ***/
}
--- 8< ---
That is, a change like this:
--- 8< ---
Index: libgweather/gweather-gconf.c
===
RCS file: /cvs/gnome/gnome-applets/libgweather/gweather-gconf.c,v
retrieving revision 1.4
diff -u -r1.4 gweather-gconf.c
--- libgweather/gweather-gconf.c31 Dec 2005 10:00:44 - 1.4
+++ libgweather/gweather-gconf.c2 Jan 2006 16:23:20 -
@@ -162,7 +162,7 @@
if (strcmp ("DEFAULT_LOCATION", _("DEFAULT_LOCATION")))
If the translator has translated the DEFAULT_LOCATION message (that
is, she did not just type "DEFAULT_LOCATION" in the translation box),
name = g_strdup (_("DEFAULT_LOCATION"));
then use the translated text the translator has provided.
else
-name = g_strdup ("Pittsburgh");
+name = g_strdup (_("Pittsburgh"));
else just put the city of Pittsburgh. The choice of Pittsburgh probably
comes from the original author of gweather, Spyros. This section is
executed when the translator has not provided any default location and
we would like the applet to work anyway. The end-user would have to
change the location to something more sensible. Making that instance of
Pittsburgh localisable is an option, however I would feel more
confortable if translators would provided a sensible default location.
In any case, if a translator went into the trouble to translate US
cities like Pittsburgh, she surely has localised all the locations in
her coutry anyway.
}
code = gweather_gconf_get_string (ctx, "location1", NULL);
--- 8< ---
To my common sense during maintaining the translation, however,
defining DEFAULT_LOCATION in English just made perfect sense,
since it's the language for internal communication between program
modules. And the mentioned code just confirmed that. So, I didn't
change the previous translator's string. But I appeared to be wrong.
I'll fix the bug soon for Thai translation.
Many thanks.
It might look strange, however, having the default location in the
weather applet appear by default in the local script, and containing the
most common location is a good tool when you present to new users.
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Page listing Localisation Bugs - please check
Dear All, One of the benefits of the new Bugzilla installed at the GNOME main servers is this page, http://bugzilla.gnome.org/browse.cgi?product=l10n It shows in a very nice way all bugs submitted for localisation; and it allows to search/list based on the language, the GNOME version, the bug severity and more. If your language appears in that list, then there are bug reports pending and they should be fixed. The Localisation Page allows for the fine search of bugs; for example, to search for bugs for French filed under GNOME HEAD which have severity normal or critical, click on these keywords and a search query will formed. Then click on the Show button and you get the search result! Each language has a localisation leader. Check for your language who is the localisation leader. Christian, is there a page which lists these contacts? Currently there are two remarks on the Bugzilla Localisation Page 1. There are a few reports pending for French. Is there a member of the French team around to trim these down? 2. Quite a few languages are present in the Bugzilla localisation page due to the weather applet issue. This gives the opportunity to try out Bugzilla and make sure the settings are ok for your language. Bugzilla is a formal bug reporting and handling tool. Spending time to learn and use it is a good skill to develop. If you have any queries, feel free to post them here. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
