Re: possible changes in gtk translations
On Mon, Mar 2, 2015 at 3:00 PM, Emmanuele Bassi eba...@gmail.com wrote: I'm afraid it's not possible currently. Damned Lies doesn't build modules. If the pot file needs a custom script to create it, the script should be runnable as is after a checkout, it cannot require a build. This should not require a full build: make -C po gtk30.pot But it will require an autogen/configure pass first. I've now made a shell script available that can be run on a pristine checkout: ./make-pot or ./make-pot properties ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: possible changes in gtk translations
Le mardi 03 mars 2015 à 07:23 -0500, Matthias Clasen a écrit : On Mon, Mar 2, 2015 at 3:00 PM, Emmanuele Bassi eba...@gmail.com wrote: I'm afraid it's not possible currently. Damned Lies doesn't build modules. If the pot file needs a custom script to create it, the script should be runnable as is after a checkout, it cannot require a build. This should not require a full build: make -C po gtk30.pot But it will require an autogen/configure pass first. I've now made a shell script available that can be run on a pristine checkout: ./make-pot or ./make-pot properties Awesome! I was now able to configure Damned Lies to use those new scripts. Thanks! Latest master statistics have just been updated: https://l10n.gnome.org/module/gtk+/ Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: possible changes in gtk translations
On Tue, Mar 3, 2015 at 3:11 PM, Claude Paroz cla...@2xlibre.net wrote: Latest master statistics have just been updated: https://l10n.gnome.org/module/gtk+/ great work, thanks ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: possible changes in gtk translations
On Fri, Feb 27, 2015 at 5:43 PM, Piotr Drąg piotrd...@gmail.com wrote: Right, it doesn't work with intltool. Claude, can damned-lies be made to generate gtk+'s pot file using make? Any update on this ? I don't want to ship GTK+ with incomplete translations, but I would hate to be shackled to a hack because you're using different tools... ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: possible changes in gtk translations
Le lundi 02 mars 2015 à 08:13 -0500, Matthias Clasen a écrit : On Fri, Feb 27, 2015 at 5:43 PM, Piotr Drąg piotrd...@gmail.com wrote: Right, it doesn't work with intltool. Claude, can damned-lies be made to generate gtk+'s pot file using make? Any update on this ? I don't want to ship GTK+ with incomplete translations, but I would hate to be shackled to a hack because you're using different tools... I'm afraid it's not possible currently. Damned Lies doesn't build modules. If the pot file needs a custom script to create it, the script should be runnable as is after a checkout, it cannot require a build. Sorry. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: possible changes in gtk translations
Hi; On 2 March 2015 at 19:55, Claude Paroz cla...@2xlibre.net wrote: Le lundi 02 mars 2015 à 08:13 -0500, Matthias Clasen a écrit : On Fri, Feb 27, 2015 at 5:43 PM, Piotr Drąg piotrd...@gmail.com wrote: Right, it doesn't work with intltool. Claude, can damned-lies be made to generate gtk+'s pot file using make? Any update on this ? I don't want to ship GTK+ with incomplete translations, but I would hate to be shackled to a hack because you're using different tools... I'm afraid it's not possible currently. Damned Lies doesn't build modules. If the pot file needs a custom script to create it, the script should be runnable as is after a checkout, it cannot require a build. This should not require a full build: make -C po gtk30.pot But it will require an autogen/configure pass first. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: possible changes in gtk translations
2015-02-26 22:12 GMT+01:00 Claude Paroz cla...@2xlibre.net: Le jeudi 26 février 2015 à 15:42 -0500, Matthias Clasen a écrit : Hi i18n team, I am itching to merge this branch in gtk: https://git.gnome.org/browse/gtk+/log/?h=wip/matthiasc/gettext It removes the extract-string hack that we currently use to pull strings out of .ui files, and instead just relies on the glade support in new enough gettext versions. glade support in gettext appeared in Version 0.18.3 - July 2013 I can easily add a check in configure that will error out if xgettext doesn't know how to deal with ui files. But I'm not sure if this will pose a problem e..g on the damn lies server. Will it ? Hi Matthias, On l10n.gnome.org, gettext 0.18.3 is installed, so it should work. I don't think it works. Strings from .ui files don't get extracted on both damned-lies and locally on Fedora 21. Best regards, -- Piotr Drąg http://raven.fedorapeople.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: possible changes in gtk translations
On Fri, Feb 27, 2015 at 1:52 PM, Piotr Drąg piotrd...@gmail.com wrote: I don't think it works. Strings from .ui files don't get extracted on both damned-lies and locally on Fedora 21. It works just fine here on f22, as far as I can tell: cd po rm gtk30.pot make gtk30.pot grep gtkprintunixdialog.ui gtk30.pot #: gtk/ui/gtkfilechooserwidget.ui:259 gtk/ui/gtkprintunixdialog.ui:135 #: gtk/ui/gtkprintunixdialog.ui:1029 #: gtk/inspector/window.ui:436 gtk/ui/gtkprintunixdialog.ui:497 #: gtk/ui/gtkpagesetupunixdialog.ui:88 gtk/ui/gtkprintunixdialog.ui:901 #: gtk/ui/gtkpagesetupunixdialog.ui:179 gtk/ui/gtkprintunixdialog.ui:957 #: gtk/ui/gtkpagesetupunixdialog.ui:229 gtk/ui/gtkprintunixdialog.ui:959 #: gtk/ui/gtkpagesetupunixdialog.ui:279 gtk/ui/gtkprintunixdialog.ui:958 #: gtk/ui/gtkpagesetupunixdialog.ui:328 gtk/ui/gtkprintunixdialog.ui:960 [...] What are you seeing ? ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: possible changes in gtk translations
27 lut 2015 22:53 Matthias Clasen matthias.clasen matthias.cla...@gmail.com@ matthias.cla...@gmail.comgmail.com matthias.cla...@gmail.com napisał(a): On Fri, Feb 27, 2015 at 1:52 PM, Piotr Drąg piotrdrag@ piotrd...@gmail.comgmail.com piotrd...@gmail.com wrote: I don't think it works. Strings from .ui files don't get extracted on both damned-lies and locally on Fedora 21. It works just fine here on f22, as far as I can tell: cd po rm gtk30.pot make gtk30.pot grep gtkprintunixdialog.ui gtk30.pot #: gtk/ui/gtkfilechooserwidget.ui:259 gtk/ui/gtkprintunixdialog.ui:135 #: gtk/ui/gtkprintunixdialog.ui:1029 #: gtk/inspector/window.ui:436 gtk/ui/gtkprintunixdialog.ui:497 #: gtk/ui/gtkpagesetupunixdialog.ui:88 gtk/ui/gtkprintunixdialog.ui:901 #: gtk/ui/gtkpagesetupunixdialog.ui:179 gtk/ui/gtkprintunixdialog.ui:957 #: gtk/ui/gtkpagesetupunixdialog.ui:229 gtk/ui/gtkprintunixdialog.ui:959 #: gtk/ui/gtkpagesetupunixdialog.ui:279 gtk/ui/gtkprintunixdialog.ui:958 #: gtk/ui/gtkpagesetupunixdialog.ui:328 gtk/ui/gtkprintunixdialog.ui:960 [...] What are you seeing ? Right, it doesn't work with intltool. Claude, can damned-lies be made to generate gtk+'s pot file using make? -- Piotr Drąg http:// http://raven.fedorapeople.orgraven.fedorapeople.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: possible changes in gtk translations
Le jeudi 26 février 2015 à 15:42 -0500, Matthias Clasen a écrit : Hi i18n team, I am itching to merge this branch in gtk: https://git.gnome.org/browse/gtk+/log/?h=wip/matthiasc/gettext It removes the extract-string hack that we currently use to pull strings out of .ui files, and instead just relies on the glade support in new enough gettext versions. glade support in gettext appeared in Version 0.18.3 - July 2013 I can easily add a check in configure that will error out if xgettext doesn't know how to deal with ui files. But I'm not sure if this will pose a problem e..g on the damn lies server. Will it ? Hi Matthias, On l10n.gnome.org, gettext 0.18.3 is installed, so it should work. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
possible changes in gtk translations
Hi i18n team, I am itching to merge this branch in gtk: https://git.gnome.org/browse/gtk+/log/?h=wip/matthiasc/gettext It removes the extract-string hack that we currently use to pull strings out of .ui files, and instead just relies on the glade support in new enough gettext versions. glade support in gettext appeared in Version 0.18.3 - July 2013 I can easily add a check in configure that will error out if xgettext doesn't know how to deal with ui files. But I'm not sure if this will pose a problem e..g on the damn lies server. Will it ? Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Tajik: GTK+ translations
Hi, For some reasons Gtk+ UI translations statistics is not updated for Tajik language at https://l10n.gnome.org/vertimus/Gtk-UI/master/po/tg Could you please, check if everything is OK. Thanks! ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
GTK+ translations
There seems to be some confusion around GTK+ translations. To clarify: GTK+ is not using intltool. Please don't put any type annotations in POTFILES.in. That breaks the build. We handle extracting strings from ui files differently. The correct way to get an updated pot for GTK+ is as follows: make make -C po gtk30.pot ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GTK+ translations
Le vendredi 19 avril 2013 à 16:01 -0400, Matthias Clasen a écrit : There seems to be some confusion around GTK+ translations. To clarify: GTK+ is not using intltool. Please don't put any type annotations in POTFILES.in. That breaks the build. We handle extracting strings from ui files differently. The correct way to get an updated pot for GTK+ is as follows: make make -C po gtk30.pot Matthias, That new method to generate the pot file is problematic for GNOME translations. Until now, no GNOME modules require to be built to be able to generate the pot file. And this has always been a rule we stick with whenever some new module wanted to use the GNOME i18n infrastructure. That sort of design change is not something that should be taken lightly. I think that requiring building a module to obtain the pot file is bad for translators in general. It is then much more difficult for translators to update translations themselves (almost impossible for the majority of them). Even at an infrastructure level, you surely know that building big modules like GTK+ is often a challenge. And if then other modules begin to use the same procedure, this will be a nightmare to maintain in the i18n point of view. I'd like to ask the GNOME community to reconsider that change and do all what's possible to keep the legacy way of generating translations. I'm not particularly attached to intltool, so if we find another tool that does a better job, why not. But let's try all possible solution that do not require to build the modules themselves. Thanks for hearing us (me?). Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GTK+ translations
El dv 19 de 04 de 2013 a les 23:46 +0200, en/na Claude Paroz va escriure: Le vendredi 19 avril 2013 à 16:01 -0400, Matthias Clasen a écrit : There seems to be some confusion around GTK+ translations. To clarify: GTK+ is not using intltool. Please don't put any type annotations in POTFILES.in. That breaks the build. We handle extracting strings from ui files differently. The correct way to get an updated pot for GTK+ is as follows: make make -C po gtk30.pot Matthias, That new method to generate the pot file is problematic for GNOME translations. Until now, no GNOME modules require to be built to be able to generate the pot file. And this has always been a rule we stick with whenever some new module wanted to use the GNOME i18n infrastructure. That sort of design change is not something that should be taken lightly. I think that requiring building a module to obtain the pot file is bad for translators in general. It is then much more difficult for translators to update translations themselves (almost impossible for the majority of them). Even at an infrastructure level, you surely know that building big modules like GTK+ is often a challenge. And if then other modules begin to use the same procedure, this will be a nightmare to maintain in the i18n point of view. I'd like to ask the GNOME community to reconsider that change and do all what's possible to keep the legacy way of generating translations. I'm not particularly attached to intltool, so if we find another tool that does a better job, why not. But let's try all possible solution that do not require to build the modules themselves. Thanks for hearing us (me?). Claude +1! Fine to move to something else, if *really* needed, but having different kinds of extraction tools and having to build the extraction tool itself seems overkill to me (and for most of translators I would guess). It's already easy, but hard for non-geek translators, to preview documentations (which are just a msgfmt -vc LANG.po itstool -m messages.po -o . ../C/*.page) that if we have to ask them to build gtk+ just to get the translation file or to check if the file is up-to-date... Cheers, -- 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 planet: http://planet.guifi.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: No GTK+ translations without a program translation?
Op So, 2009-08-02 om 20:21 +0200 skryf Frederic Peters: F Wolff wrote: I'm seeing some strange behaviour from time to time that I hope somebody here can help me trace/understand. Some GTK+ applications seem to not be using my Afrikaans GTK+ translations. I'm still trying to collect some information, so can't say exactly when it happens. The behaviour seems to have changed in the last year, although I can't remember exactly. Sounds like it could be a consequence of http://bugzilla.gnome.org/show_bug.cgi?id=503071 It sounds correct for some of my issues, yes. Now still to figure out about Evolution and Virtaal. It seems that pygtk might be the reason for Virtaal. Th issue explained in the bug is quite unfortunate for me. I thought about the implications of RTL languages, but it is a pity that it works like this now for all languages. While I guess the current behaviour is better for RTL languages, it removed what I considered a feature. For small languages, just translating some parts of GTK+ used to provide an immediate boost for the localised feel of the desktop, since some of the most used GUI elements would be translated, and it provides motivation early on that is important for a new team or translator. While I understand that not everybody likes a semi-translated desktop, there are also advantages to always having the same accelerators for stock items whether the rest of the application is translated or not. Even setting LANGUAGE to af still does not activate the GTK+ translations in an untranslated application. On the positive side, if I set LANGUAGE to af:nl it works as expected, with a Dutch application and Afrikaans coming from GTK+. Now: any idea why this would not work the same way in a pygtk application? It would be best to have the same behaviour for the sake of RTL languages at least. Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/pseudolocalisation-podebug-2 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
No GTK+ translations without a program translation?
Hallo all I'm seeing some strange behaviour from time to time that I hope somebody here can help me trace/understand. Some GTK+ applications seem to not be using my Afrikaans GTK+ translations. I'm still trying to collect some information, so can't say exactly when it happens. The behaviour seems to have changed in the last year, although I can't remember exactly. In Evolution when writing a new e-mail, everything under the Edit menu (Undo, Redo, Cut, Copy, Paste...) is in English, even though I have them translated in my gtk20.mo. I have an Afrikaans translation for Evolution installed. These strings don't appear in the po file for Evolution, so I really expect these to be the strings from GTK+. In Gimp, none of the GTK+ strings are translated. Not stock menu labels, nor standard dialogues such as File-Open or Help-About. I don't have any Afrikaans translation of Gimp installed. I can see similar behaviour for Gedit if I rename gedit.mo to something else. If I install a gimp.mo from another language into the Afrikaans directory, _some_ Afrikaans translations from GTK+ are used. Standard dialogs (like File-Open and Help-About) seem to use their Afrikaans translations, but stock menu items not. For some weird reason it seems that Gimp has all the stock items duplicated in its own file. In Virtaal the GTK+ stock menus and dialogues are translated in Afrikaans whether I have the Afrikaans translation of Virtaal installed or not. Does anybody have an idea why the GTK+ translations are sometimes not being used? Is it related to whether glade is used? Perhaps the programming language? (Virtaal is written in Python and uses glade) Any help appreciated. Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/pseudolocalisation-podebug-2 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: No GTK+ translations without a program translation?
F Wolff wrote: I'm seeing some strange behaviour from time to time that I hope somebody here can help me trace/understand. Some GTK+ applications seem to not be using my Afrikaans GTK+ translations. I'm still trying to collect some information, so can't say exactly when it happens. The behaviour seems to have changed in the last year, although I can't remember exactly. Sounds like it could be a consequence of http://bugzilla.gnome.org/show_bug.cgi?id=503071 Frederic ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Uploading initial gtk translations
On Sun, Sep 11, 2005 at 12:25:26AM +0200, Erdal Ronahi wrote: Do you know a solution? Is it possible to change some variables manually to make Ubuntu use the Kurdish language pack? You should post a request for a Kurdish locale in rosetta-users and we'll see what we can do. -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ signature.asc Description: Digital signature ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Uploading initial gtk translations
Hi Jordi, it was not me who committed the files, I have used the CVS for the first time today. I hope I didn't break too many things. I have only added lines to the changelogs and configure.in. Now we have a problem in the Kurdish team, I think you also read the bugs in Ubuntu. We have a Kurdish language pack which contains the translations we make for GNOME, but it is unusable, because there is no Kurdish locale in Ubuntu. (https://bugzilla.ubuntu.com/show_bug.cgi?id=13871) Do you know a solution? Is it possible to change some variables manually to make Ubuntu use the Kurdish language pack? Regards, Erdal 2005/9/2, Jordi Mallach [EMAIL PROTECTED]: Hi Erdal, You recently committed a ku.po file for GTK+, and added ku to ALL_LINGUAS. This is a reminder to everyone, that when uploading files to modules with multiple po directories, you should add a file for your language into every directory that needs to have one, or the build will fail. I have added an empty ku.po to po-properties, which will fix the build. Jordi -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDGBY5JYSUupF6Il4RAogrAJ9KZrIIdreYP0k6+53gh3DV+QJ9sgCeKK/e JY0jkeNN4u4Ieh96mI8N8t4= =eDNQ -END PGP SIGNATURE- -- http://www.ferheng.org http://www.pckurd.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
