What are the current ChangeLog procedures?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm about to start a cleanup of the Norwegian Nynorsk translations, which have been degrading for a couple of years. I notice that some things have changed in the organizations of some modules. Has the GTP standardized on not using po/ChangeLog anymore, or is that up to each module's maintainer? It's rather tricky to make commit scripts when each module has different rules for committing. - -- Åsmund Skjæveland -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklsdqUACgkQKeJUaVS5dc7ynQCfcAbu27wPiI7pECGZLLXyV5uP ZqsAn2657dp6bg3vVdMLG2nJgrTBiM8H =7s8n -END PGP SIGNATURE- ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Yoruba, Hausa and Igbo (yo, ha, ig) po files
Hi, Andre Klapper wrote: This is about http://www.gnome.org/~tthurman/yo-ha-ig/ . These are .po files extracted from a Nigerian distro called Wazobia Linux. Several KDE and GNOME applications were translated into the three languages in the subject line, a user has found a disk image, extracted the .mo files, decompiled them to .po and sent them to Thomas Thurman. ... So to me it boils down to the question: Can we just take the .po files without asking anybody? and (like Johannes wrote earlier) if a translation can be considered a derived work. I think Johannes has almost asked the right question. The question is whether translating an application results in a derived work. Am I missing something, or isn't the answer obviously yes? *If* the translated application is derived from the original, then if the original application is GPL, you can just take the .po file, and credit the person/people who did the translation. If the app is LGPL, the same thing applies. For any BSD-type licence, you'll need confirmation from Wazobia that their translations were released under the same licence. This seems like the kind of thing that the FSF and the SFLC have probably thought about already. Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Yoruba, Hausa and Igbo (yo, ha, ig) po files
On Tue, Jan 13, 2009 at 8:25 AM, Dave Neary dne...@gnome.org wrote: Hi, Andre Klapper wrote: This is about http://www.gnome.org/~tthurman/yo-ha-ig/ . These are .po files extracted from a Nigerian distro called Wazobia Linux. Several KDE and GNOME applications were translated into the three languages in the subject line, a user has found a disk image, extracted the .mo files, decompiled them to .po and sent them to Thomas Thurman. ... So to me it boils down to the question: Can we just take the .po files without asking anybody? and (like Johannes wrote earlier) if a translation can be considered a derived work. I think Johannes has almost asked the right question. The question is whether translating an application results in a derived work. Am I missing something, or isn't the answer obviously yes? *If* the translated application is derived from the original, then if the original application is GPL, you can just take the .po file, and credit the person/people who did the translation. If the app is LGPL, the same thing applies. For any BSD-type licence, you'll need confirmation from Wazobia that their translations were released under the same licence. I *think* (though I will check with SFLC shortly to make sure) that this is not the case. Just because it *should* have been released under GPL doesn't mean it *is* released under GPL, or that we can treat it that way. It is still under 'their' copyright until either they or a court agree that it should be GPL as a remedy for the violation. This seems like the kind of thing that the FSF and the SFLC have probably thought about already. Possibly, though I've never heard of a case of abandonware translations before. Luis ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What are the current ChangeLog procedures?
Le mardi 13 janvier 2009 à 12:10 +0100, Åsmund Skjæveland a écrit : I'm about to start a cleanup of the Norwegian Nynorsk translations, which have been degrading for a couple of years. I notice that some things have changed in the organizations of some modules. Has the GTP standardized on not using po/ChangeLog anymore, or is that up to each module's maintainer? It's rather tricky to make commit scripts when each module has different rules for committing. No, the GTP is victim of a loose policy among maintainers, as it seems that the ChangeLog files are less and less popular, especially in the DVCS world. Hopefully we'll find some unity again about ChangeLogs (files or messages) after the DVCS (git?) migration. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Evolution - new string
Hi, I committed slightly modified patch from bug [1] to evolution's trunk, which contains one new string. Bye, Milan [1] http://bugzilla.gnome.org/show_bug.cgi?id=489437 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Yoruba, Hausa and Igbo (yo, ha, ig) po files
On Mon, Jan 12, 2009 at 09:43:51PM -0500, Thomas Thurman wrote: Maybe in future we need to make the gettext tools enforce a rule that the header block of a .po file contains licence information, instead of assuming it's okay to leave it in the comments. Then we should also enforce compiler (gcc) to add license information to binaries... Do we really want that? -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | |jabber: mar...@jabber.sk | +---+ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Yoruba, Hausa and Igbo (yo, ha, ig) po files
Ysgrifennodd Marcel Telka: On Mon, Jan 12, 2009 at 09:43:51PM -0500, Thomas Thurman wrote: Maybe in future we need to make the gettext tools enforce a rule that the header block of a .po file contains licence information, instead of assuming it's okay to leave it in the comments. Then we should also enforce compiler (gcc) to add license information to binaries... Do we really want that? Yes, I'd like that too. Actually, it would be really useful to warn people linking non-GPL binaries against GPL libraries. But I don't think the cases are parallel. You can't point some tool at a compiled binary and get the source code back. You can throw .mo files at msgunfmt and get *almost* the original .po back, but lacking the comments; if the comments are just comments, that's fine because they're just hints to humans, but if they contain actual useful metadata, there's no reason that metadata shouldn't live in the header block along with the metadata we already carry, like contact email address and name of the last translator. Honestly, the only metadata that *needs* to be in the header block is the content encoding; everything else is for human convenience (author name and contact details could live in comments as licence data already does, date can be figured out from source control, project can be figured out from the place the .po or .mo file is found, language team can be figured out from the pathname and the project name). There's no reason not to add another field to the mix to stop cases like this from happening again. peace Thomas ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Epiphany branched for 2.26
Hi; Epiphany was branched for Gnome 2.26 (from the gnome-2-24 branch). The branch is named gnome-2-26 as usual. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Epiphany branched for 2.26
Hi, I think it's done, in GNOME 2.26 set shows the 2.26 branch, but when I added it I had to also keep the HEAD branch in the GNOME 2.26 release set. Claude it's this the expected way or should be added a Future release set while we wait for having a 2.28 release set? Cheers, El dt 13 de 01 de 2009 a les 18:53 +0100, en/na Christian Persch va escriure: Hi; Epiphany was branched for Gnome 2.26 (from the gnome-2-24 branch). The branch is named gnome-2-26 as usual. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- 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
Re: Yoruba, Hausa and Igbo (yo, ha, ig) po files
Luis Villa wrote: On Tue, Jan 13, 2009 at 8:25 AM, Dave Neary dne...@gnome.org wrote: Hi, Andre Klapper wrote: This is about http://www.gnome.org/~tthurman/yo-ha-ig/ . These are .po files extracted from a Nigerian distro called Wazobia Linux. Several KDE and GNOME applications were translated into the three languages in the subject line, a user has found a disk image, extracted the .mo files, decompiled them to .po and sent them to Thomas Thurman. ... So to me it boils down to the question: Can we just take the .po files without asking anybody? and (like Johannes wrote earlier) if a translation can be considered a derived work. I think Johannes has almost asked the right question. The question is whether translating an application results in a derived work. Am I missing something, or isn't the answer obviously yes? *If* the translated application is derived from the original, then if the original application is GPL, you can just take the .po file, and credit the person/people who did the translation. If the app is LGPL, the same thing applies. For any BSD-type licence, you'll need confirmation from Wazobia that their translations were released under the same licence. I *think* (though I will check with SFLC shortly to make sure) that this is not the case. Just because it *should* have been released under GPL doesn't mean it *is* released under GPL, or that we can treat it that way. It is still under 'their' copyright until either they or a court agree that it should be GPL as a remedy for the violation. This seems like the kind of thing that the FSF and the SFLC have probably thought about already. Possibly, though I've never heard of a case of abandonware translations before. I've been included in the middle of this thread, so the following lacks context and is a bunch of general statements (as opposed to being specific legal advice about the situation and files currently being discussed). Still, I think I can help. If a work containing a bunch of strings is GPL-licensed, then those strings are also GPL-licensed. If you take a bunch of strings from a copyrighted work, translate them and then assemble them into a .po file, you have, in non-trivial cases, created a derivative work. Works derived from GPL-licensed works are not *automatically* GPL-licensed. There are a number of reasons for this, both legal, textual and political. Suffice it to say, though, that while the GPL gives you rights to things that are GPL, it says nothing about what *is* GPL. There are consequences to releasing some code as non-GPL, but those consequences do not include your code being GPL-licensed automatically. In short, Luis is right as a general matter. All of that said, it sounds like there's context here that matters. Luis, if you want to give me a call, I can give you a more considered opinion. Hope this helps, James ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Yoruba, Hausa and Igbo (yo, ha, ig) Licensing
I mounted the disk image and poked around a bit. There are no .po files in the root filesystem, but there is a documentation folder: /usr/share/doc/wazobia-release-1/ which contains licensing information, including the GPL and a README/eula file that explain the contents of the CD being licensed under the GPL. It's pretty much all verbatim from an FC4 image. I've put a (temporary) tarball at http://www.chrismurf.com/waz-rel1.tgz of that folder for others who want to have a look. Since they bothered to change the folder name to wazobia-release-1, it seems like they have explicitly selected the GPL? I've got the images mounted, and I'm happy to pull out other things if that's useful. The *.mo files are all there, but there's no *.po files. - Chris Murphy (a planet gnome lurker) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Yoruba, Hausa and Igbo (yo, ha, ig) Licensing
Ysgrifennodd Chris Murphy: I mounted the disk image and poked around a bit. There are no .po files in the root filesystem, but there is a documentation folder: /usr/share/doc/wazobia-release-1/ which contains licensing information, including the GPL and a README/eula file that explain the contents of the CD being licensed under the GPL. Now that IS very interesting. So they explicitly put their work under the GPL, then? I've got the images mounted, and I'm happy to pull out other things if that's useful. The *.mo files are all there, but there's no *.po files. Thanks for doing that. The person who sent me the .mo and .po files told me he'd re-created the .po files using msgunfmt (a standard tool that decompiles back to .po for just such cases as these). Thomas ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Yoruba, Hausa and Igbo (yo, ha, ig) Licensing
2009/1/13 Chris Murphy chrism...@gmail.com: it seems like they have explicitly selected the GPL? I'm leaving the issue to the actual legal experts. Just noting that assuming that we make sure the translations are actually GPL, we need to be careful about using the translations in GNOME modules released under LGPL or other non-GPL licenses. Roozbeh ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Yoruba, Hausa and Igbo (yo, ha, ig) Licensing
I chroot-ed into the image and played with rpm a bit - the files were originally from a package called locales-ng. I don't know anything about the localization process, but at least some of them look like source files of some sort. For somebody who knows more about localization, all the files included in locales-ng are now in a tarball at : http://www.chrismurf.com/locales-ng.tgz. They also have licensing information at the top, Distribution and use is free, also for commercial purposes. If somebody can give me a better idea what I'm looking for (provided this isn't it) I'm happy to keep digging. Best, Chris On Tue, Jan 13, 2009 at 3:50 PM, Roozbeh Pournader rooz...@gmail.comwrote: 2009/1/13 Chris Murphy chrism...@gmail.com: it seems like they have explicitly selected the GPL? I'm leaving the issue to the actual legal experts. Just noting that assuming that we make sure the translations are actually GPL, we need to be careful about using the translations in GNOME modules released under LGPL or other non-GPL licenses. Roozbeh ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Yoruba, Hausa and Igbo (yo, ha, ig) Licensing
And for good measure I grabbed the files from the translations-[ha,ig,yo] packages and tarred them up. Everything is available from the folder: http://chrismurf.com/nigerian-translations/, including the files I referenced earlier. Apologies for not consolidating emails. - c On Tue, Jan 13, 2009 at 4:05 PM, Chris Murphy chrism...@gmail.com wrote: I chroot-ed into the image and played with rpm a bit - the files were originally from a package called locales-ng. I don't know anything about the localization process, but at least some of them look like source files of some sort. For somebody who knows more about localization, all the files included in locales-ng are now in a tarball at : http://www.chrismurf.com/locales-ng.tgz. They also have licensing information at the top, Distribution and use is free, also for commercial purposes. If somebody can give me a better idea what I'm looking for (provided this isn't it) I'm happy to keep digging. Best, Chris On Tue, Jan 13, 2009 at 3:50 PM, Roozbeh Pournader rooz...@gmail.comwrote: 2009/1/13 Chris Murphy chrism...@gmail.com: it seems like they have explicitly selected the GPL? I'm leaving the issue to the actual legal experts. Just noting that assuming that we make sure the translations are actually GPL, we need to be careful about using the translations in GNOME modules released under LGPL or other non-GPL licenses. Roozbeh ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
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 LINGUAS. Is it possible to remove altogether?
EXAMPLE
This assumes you have the 'git' package ('git-core' if you use
Debian/Ubuntu) installed.
A. Cloning
String additions to anjuta
Hi! Anjuta got some new strings describing the version control states (such as modified, added, removed, etc.) Thanks and regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ 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
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.
- 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).
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).
Cheers,
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
├─ 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
│
Re: Using Git and separating translations into their own l10n-LL repository
On Tue, Jan 13, 2009 at 11:31 PM, Gil Forcada gforc...@gnome.org 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 ├─ 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 │ │ ├─
evolution reuses timezones?
Hi, While reviewing Catalan translation of Evolution I found that there are still present the timezones strings, even if [1] is fixed. I also update another bug [2] to also reuse the countries and cities names. Anyone knows more about those issues? Cheers and happy translating :) [1] http://bugzilla.gnome.org/show_bug.cgi?id=352287 [2] http://bugzilla.gnome.org/show_bug.cgi?id=551705 -- 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
[Bug 567703] New: Language Selection not listed properly
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=567703 l10n | other | Ver: unspecified Summary: Language Selection not listed properly Product: l10n Version: unspecified Platform: Other OS/Version: All Status: UNCONFIRMED Keywords: L10N Severity: normal Priority: Normal Component: other AssignedTo: gnome-i18n@gnome.org ReportedBy: wynn_da...@hotmail.com QAContact: ment...@menthos.com GNOME version: Unspecified GNOME milestone: Unspecified Incorrect translation Application: gdm Incorrect text: This is a general error in the language selection in gdm. Currently, the choice of languages is dependent on the current language chosen for gdm. For instance, I have a PC setup to allow for both Spanish and English. If gdm is in English mode, the selections are listed as Spanish and English, with all country options listed in English. If its in Spanish mode, choices are presented as Spanish, Espanol, English, and Ingles (sorry about any missing accent marks, and yes, gdm lists all four options when in Spanish mode). But this should not be -- the list should not be dependent on the language mode gdm is currently stuck in. Furthermore, after choosing a language, it asks a question to confirm whether the user wants to use this mode for this session only or to make it the default. But this message is in the current gdm language, not the one just chosen. So, if gdm was currently in Spanish, and the user chose English, the message comes up in Spanish. If gdm was in English mode, whether the user chooses an English or Spanish selection, the message appears in English. Should be: Real world example: here in the USA, we have ATM and Point of Sale credit card machines that have the ability to present messages in English, Spanish, and sometimes other languages. But if its currently in English mode, they don't list an option for Spanish?, they list an option for Espanol?. The person selecting the language needs to be able to read his language, and his country choice, in his native language. So, Spanish options should never say Spanish -- they should always say Espanol, and English options should never say Ingles, they should always say English, with all country options being listed in the native speakers language. (So, I should always see English (USA) as English (USA), not Ingles (however Spanish refers to the USA)). After choosing a language, the verification message should always be presented in the chosen language, not the language mode that gdm is currently in. The cancel button should always be presented with an established icon indicating cancel, so the user can still choose cancel, if he made a mistake in his selection. -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=567703. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[Bug 567703] Language Selection not listed properly
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=567703 l10n | other | Ver: unspecified David Wynn changed: What|Removed |Added OS/Version|All |Linux -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=567703. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
How to translate with msgctxt ?
Hello everybody, Gtranslator does not (yet) let us translate files with msgctxt texts. When I want to do so, I have to do it with gedit (or lokalize). Is there another way to do? Thanks, Yannig Marchegay ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[Bug 567703] Language Selection not listed properly
If you have any questions why you received this email, please see the text at the end of this email. Replies to this email are NOT read, please see the text at the end of this email. You can add comments to this bug at: http://bugzilla.gnome.org/show_bug.cgi?id=567703 gdm | general | Ver: unspecified Christian Rose changed: What|Removed |Added CC||ment...@menthos.com AssignedTo|gnome-i18n@gnome.org|gdm-ma...@gnome.bugs Component|other |general Product|l10n|gdm QAContact|ment...@menthos.com |gdm-ma...@gnome.bugs --- Comment #1 from Christian Rose 2009-01-14 07:23 UTC --- This would be a problem with the i18n of gdm -- according to your description of the problem, the translations (l10n) are not incorrect per se. Reassigning to gdm. -- See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received this email, why you can't respond via email, how to stop receiving emails (or reduce the number you receive), and how to contact someone if you are having problems with the system. You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=567703. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Epiphany branched for 2.26
Le mardi 13 janvier 2009 à 20:08 +0100, Gil Forcada a écrit : Hi, I think it's done, in GNOME 2.26 set shows the 2.26 branch, but when I added it I had to also keep the HEAD branch in the GNOME 2.26 release set. Claude it's this the expected way or should be added a Future release set while we wait for having a 2.28 release set? In fact, in the form http://l10n.gnome.org/module/module/edit/branches/ you're only editing the association between branches and releases. You can safely delete an association and the branch itself won't be deleted. So currently epiphany HEAD is not linked to any release. Claude El dt 13 de 01 de 2009 a les 18:53 +0100, en/na Christian Persch va escriure: Hi; Epiphany was branched for Gnome 2.26 (from the gnome-2-24 branch). The branch is named gnome-2-26 as usual. 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
