Re: gettext

[philip . chimento]

On Fri, Aug 19, 2016 at 4:54 PM Patrick Welche  wrote:

> Maybe "remove underscores from .desktop files" could be added to the
>
>   "Add rules for merging translations back into non-source files"
>
> of the useful https://wiki.gnome.org/MigratingFromIntltoolToGettext
> page?
>

Done. For next time you (and everyone else) are also explicitly invited to
add any additional information you discovered while migrating :-)

Regards,
Philip C
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Daiki Ueno]

Patrick Welche  writes:

> Another surprise:
>
> $ autoreconf -vif
> ...
> $ mkdir obj
> $ cd obj
> $ ../configure
> ...
> $ cd po
> $ ls
> Makefile Makefile.in  POTFILES
> $ make cs.gmo
> cd ../../po && rm -f cs.gmo && /usr/bin/msgfmt -c --statistics
> --verbose -o cs.gmo cs.po
> 250 translated messages.
> $ ls
> Makefile Makefile.in  POTFILES
> $ ls ../../po/cs.gmo
> ../../po/cs.gmo
>
> Problem is, the Makefile.in.in comes from gettext 19.8.1 so fiddling to
> use objdir is "interesting".
>
> Non-source tree builds impossible?

I haven't checked other implementations yet, but I would say that the
behaviour is normal, at least in the context of automake:
http://www.gnu.org/software/automake/manual/automake.html#VPATH-Builds
  [...]
 The build tree is rooted in the directory in which ‘configure’ was
  run, and is populated with all object files, programs, libraries, and
  other derived files built from the sources (and _hence not distributed_).

Since .gmo files are distributed, like ./configure, .info files, or Vala
generated .c files, they should be generated in $srcdir, rather than
$builddir.

Regards,
-- 
Daiki Ueno
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Patrick Welche]

On Fri, Aug 19, 2016 at 06:10:02PM +0100, Patrick Welche wrote:
> Problem is, the Makefile.in.in comes from gettext 19.8.1 so fiddling to
> use objdir is "interesting".

s/objdir/builddir/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Patrick Welche]

Another surprise:

$ autoreconf -vif
...
$ mkdir obj
$ cd obj
$ ../configure
...
$ cd po
$ ls
Makefile Makefile.in  POTFILES
$ make cs.gmo
cd ../../po && rm -f cs.gmo && /usr/bin/msgfmt -c --statistics --verbose -o 
cs.gmo cs.po
250 translated messages.
$ ls
Makefile Makefile.in  POTFILES
$ ls ../../po/cs.gmo
../../po/cs.gmo

Problem is, the Makefile.in.in comes from gettext 19.8.1 so fiddling to
use objdir is "interesting".

Non-source tree builds impossible?


Cheers,

Patrick
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Patrick Welche]

Surprise:

Given a desktop file of the form:

[Desktop Entry]
_Name=Dasher
_GenericName=Predictive text entry
_Comment=Enter text without a keyboard
Exec=dasher
...

intltool correctly generates translation, whereas

  /usr/pkg/bin/msgfmt --desktop --template dasher.desktop.in -d ../../po -o 
dasher.desktop
dasher.desktop.in:3:0: warning: invalid non-blank line
dasher.desktop.in:4:0: warning: invalid non-blank line
dasher.desktop.in:5:0: warning: invalid non-blank line

and the first 3 lines are omitted from dasher.desktop


Removing the underscores, intltool does not generate translations, but
msgfmt is happy.

Maybe "remove underscores from .desktop files" could be added to the

  "Add rules for merging translations back into non-source files"

of the useful https://wiki.gnome.org/MigratingFromIntltoolToGettext
page?


Cheers,

Patrick
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Javier Jardón]

Hi,

On 22 April 2016 at 08:49, Patrick Welche  wrote:
> All the docs for the maintainer side of i18n I found use intltool and
> glib-gettext, yet I see bugzilla bugs open to use upstream gettext /
> autopoint.

Sorry for reopen an old thread; I've been submitting some patches and
if you want to keep track of the progress / help, the current meta bug
to track this porting work is [1]

Cheers,
Javier Jardón

[1] https://bugzilla.gnome.org/show_bug.cgi?id=763587
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Alberts Muktupāvels]

On Wed, May 18, 2016 at 9:39 AM,  wrote:

> On Tue, May 17, 2016 at 2:36 AM Daiki Ueno  wrote:
>
>> philip.chime...@gmail.com writes:
>>
>> > After trying it out, it's very unfortunate that msgfmt doesn't have an
>> > argument allowing you to specify a custom ITS rule; it only detects
>> > ones that have been installed into the Gettext data directories.
>>
>> The xgettext's --its option was originally added for testing purpose (to
>> check if a given ITS file works as expected).  The suggested way to
>> specify custom ITS rules is to install those files in
>> /usr/share/gettext, because of ...
>>
>> > Also, if you use xgettext's --its option to specify a custom ITS rule,
>> > then it seems not to pick up translatable strings from C sources
>> > anymore; but without it, it won't pick them up from the XML
>> > files. I'll check again tomorrow and otherwise report this as a bug.
>>
>> ... this.  It is the same limitation that -L, -k, --flags options are
>> effective for all input files.  There was a discussion to support
>> per-file options, but it is not implemented yet:
>> http://article.gmane.org/gmane.comp.gnu.gettext.bugs/863
>>
>> Anyway, thanks for writing up the document!
>>
>
> Thanks for the clarification!
>
> Do you know of an Autotools workflow with xgettext / msgfmt that could
> replace the one I described with itstool in the document?
>
> I'm thinking specifically of a case where the XML format is ad-hoc to the
> package (such as gtksourceview), and therefore the ITS rule can't be
> installed into /usr/share/gettext because then the package would require
> itself to be installed in order to be able to run make dist, for example.
>
> Thanks,
> Philip
>

Probably related bug:
https://bugzilla.gnome.org/show_bug.cgi?id=755466

-- 
Alberts Muktupāvels
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[philip . chimento]

On Tue, May 17, 2016 at 2:36 AM Daiki Ueno  wrote:

> philip.chime...@gmail.com writes:
>
> > After trying it out, it's very unfortunate that msgfmt doesn't have an
> > argument allowing you to specify a custom ITS rule; it only detects
> > ones that have been installed into the Gettext data directories.
>
> The xgettext's --its option was originally added for testing purpose (to
> check if a given ITS file works as expected).  The suggested way to
> specify custom ITS rules is to install those files in
> /usr/share/gettext, because of ...
>
> > Also, if you use xgettext's --its option to specify a custom ITS rule,
> > then it seems not to pick up translatable strings from C sources
> > anymore; but without it, it won't pick them up from the XML
> > files. I'll check again tomorrow and otherwise report this as a bug.
>
> ... this.  It is the same limitation that -L, -k, --flags options are
> effective for all input files.  There was a discussion to support
> per-file options, but it is not implemented yet:
> http://article.gmane.org/gmane.comp.gnu.gettext.bugs/863
>
> Anyway, thanks for writing up the document!
>

Thanks for the clarification!

Do you know of an Autotools workflow with xgettext / msgfmt that could
replace the one I described with itstool in the document?

I'm thinking specifically of a case where the XML format is ad-hoc to the
package (such as gtksourceview), and therefore the ITS rule can't be
installed into /usr/share/gettext because then the package would require
itself to be installed in order to be able to run make dist, for example.

Thanks,
Philip
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Daiki Ueno]

philip.chime...@gmail.com writes:

> After trying it out, it's very unfortunate that msgfmt doesn't have an
> argument allowing you to specify a custom ITS rule; it only detects
> ones that have been installed into the Gettext data directories.

The xgettext's --its option was originally added for testing purpose (to
check if a given ITS file works as expected).  The suggested way to
specify custom ITS rules is to install those files in
/usr/share/gettext, because of ...

> Also, if you use xgettext's --its option to specify a custom ITS rule,
> then it seems not to pick up translatable strings from C sources
> anymore; but without it, it won't pick them up from the XML
> files. I'll check again tomorrow and otherwise report this as a bug.

... this.  It is the same limitation that -L, -k, --flags options are
effective for all input files.  There was a discussion to support
per-file options, but it is not implemented yet:
http://article.gmane.org/gmane.comp.gnu.gettext.bugs/863

Anyway, thanks for writing up the document!

Regards,
-- 
Daiki Ueno
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[philip . chimento]

On Mon, May 16, 2016 at 10:52 PM  wrote:

> On Mon, May 16, 2016 at 4:08 AM Matthias Clasen 
> wrote:
>
>> On Mon, May 16, 2016 at 12:36 AM,   wrote:
>>
>> >
>> >
>> > I've done some work on this; I rewrote the wiki page titled "Localize
>> using
>> > Gettext and Intltool" [1] so that it doesn't mention intltool anymore.
>> Since
>> > it's a pretty drastic revision, I put it in a paste [2], maybe someone
>> wants
>> > to check if I haven't been too overzealous in deleting?
>> >
>> > Furthermore, here's the migration guide [3]. Caveats are that I did this
>> > mostly by looking back at some commits that I made a few months ago, and
>> > I've never done it for AppData files, so it could probably use some
>> > independent verification.
>>
>> I've briefly looked over the migration guide. Some comments/corrections:
>>
>> - Current gettext _does_ support its files, and some gnome projects
>> install their own now: glib installs gschema.its, and gtk+ installs
>> gtkbuilder.its, etc. The its support may be a 0.19.7 addition.
>>
>> - There is some unclear information about what file formats require
>> merging translations back, and which don't: gschema and gtkbuilder
>> files reference the gettext domain for translation at runtime - you
>> don't merge translations back into the xml.
>>
>
> Thanks, Matthias. Indeed it is a 0.19.7 feature. I've updated the
> migration guide and now I'll go update my own project to 0.19.7 to make
> sure my advice is correct :-P
>

After trying it out, it's very unfortunate that msgfmt doesn't have an
argument allowing you to specify a custom ITS rule; it only detects ones
that have been installed into the Gettext data directories. It seems this
can be worked around by specifying a local path in the GETTEXTDATADIR(S)
environment variables. As I had to find that out by reading the Gettext
source, I'm not sure how well it can be relied on; maybe the itstool hack
is better if you have to merge translations back.

Also, if you use xgettext's --its option to specify a custom ITS rule, then
it seems not to pick up translatable strings from C sources anymore; but
without it, it won't pick them up from the XML files. I'll check again
tomorrow and otherwise report this as a bug.

I've reverted the last section of the migration guide back to the itstool
instructions for now.

Regards,
Philip C
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[philip . chimento]

On Mon, May 16, 2016 at 4:08 AM Matthias Clasen 
wrote:

> On Mon, May 16, 2016 at 12:36 AM,   wrote:
>
> >
> >
> > I've done some work on this; I rewrote the wiki page titled "Localize
> using
> > Gettext and Intltool" [1] so that it doesn't mention intltool anymore.
> Since
> > it's a pretty drastic revision, I put it in a paste [2], maybe someone
> wants
> > to check if I haven't been too overzealous in deleting?
> >
> > Furthermore, here's the migration guide [3]. Caveats are that I did this
> > mostly by looking back at some commits that I made a few months ago, and
> > I've never done it for AppData files, so it could probably use some
> > independent verification.
>
> I've briefly looked over the migration guide. Some comments/corrections:
>
> - Current gettext _does_ support its files, and some gnome projects
> install their own now: glib installs gschema.its, and gtk+ installs
> gtkbuilder.its, etc. The its support may be a 0.19.7 addition.
>
> - There is some unclear information about what file formats require
> merging translations back, and which don't: gschema and gtkbuilder
> files reference the gettext domain for translation at runtime - you
> don't merge translations back into the xml.
>

Thanks, Matthias. Indeed it is a 0.19.7 feature. I've updated the migration
guide and now I'll go update my own project to 0.19.7 to make sure my
advice is correct :-P

Regards,
Philip C
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Matthias Clasen]

On Mon, May 16, 2016 at 12:36 AM,   wrote:

>
>
> I've done some work on this; I rewrote the wiki page titled "Localize using
> Gettext and Intltool" [1] so that it doesn't mention intltool anymore. Since
> it's a pretty drastic revision, I put it in a paste [2], maybe someone wants
> to check if I haven't been too overzealous in deleting?
>
> Furthermore, here's the migration guide [3]. Caveats are that I did this
> mostly by looking back at some commits that I made a few months ago, and
> I've never done it for AppData files, so it could probably use some
> independent verification.

I've briefly looked over the migration guide. Some comments/corrections:

- Current gettext _does_ support its files, and some gnome projects
install their own now: glib installs gschema.its, and gtk+ installs
gtkbuilder.its, etc. The its support may be a 0.19.7 addition.

- There is some unclear information about what file formats require
merging translations back, and which don't: gschema and gtkbuilder
files reference the gettext domain for translation at runtime - you
don't merge translations back into the xml.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[philip . chimento]

On Sun, Apr 24, 2016 at 9:05 PM  wrote:

> On Fri, Apr 22, 2016 at 6:39 AM Michael Catanzaro 
> wrote:
>
>> On Fri, 2016-04-22 at 09:54 +0100, Philip Withnall wrote:
>> > Upstream gettext and autopoint are the recommended tools to use,
>> > although you will need the latest versions of them in order to get
>> > support for all the things which intltool supports (namely, AppData,
>> > support for which was added in gettext 0.19.6).
>>
>> We really need an intltool -> pure gettext transition guide, if anyone
>> feels up for taking that on, because it's not at all clear how this is
>> supposed to work.
>>
>
> I've recently done that transition on one of my own projects, so let me
> see if I have time to write up a migration guide.
>

I've done some work on this; I rewrote the wiki page titled "Localize using
Gettext and Intltool" [1] so that it doesn't mention intltool anymore.
Since it's a pretty drastic revision, I put it in a paste [2], maybe
someone wants to check if I haven't been too overzealous in deleting?

Furthermore, here's the migration guide [3]. Caveats are that I did this
mostly by looking back at some commits that I made a few months ago, and
I've never done it for AppData files, so it could probably use some
independent verification.

Regards,
Philip C

[1]
https://wiki.gnome.org/TranslationProject/DevGuidelines/Localize%20using%20gettext%20and%20intltool
[2] https://gist.github.com/ptomato/0e70598951f1ce809d5e9625a0b0dd8e
[3] https://wiki.gnome.org/MigratingFromIntltoolToGettext
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[philip . chimento]

On Fri, Apr 22, 2016 at 6:39 AM Michael Catanzaro 
wrote:

> On Fri, 2016-04-22 at 09:54 +0100, Philip Withnall wrote:
> > Upstream gettext and autopoint are the recommended tools to use,
> > although you will need the latest versions of them in order to get
> > support for all the things which intltool supports (namely, AppData,
> > support for which was added in gettext 0.19.6).
>
> We really need an intltool -> pure gettext transition guide, if anyone
> feels up for taking that on, because it's not at all clear how this is
> supposed to work.
>

I've recently done that transition on one of my own projects, so let me see
if I have time to write up a migration guide.

Philip C.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Christian Hergert]

On 04/22/2016 10:08 AM, Sébastien Wilmet wrote:
> On Fri, Apr 22, 2016 at 08:39:33AM -0500, Michael Catanzaro wrote:
>> > We really need an intltool -> pure gettext transition guide, if anyone
>> > feels up for taking that on, because it's not at all clear how this is
>> > supposed to work.
> gettext is well documented. For maintainers:
> http://www.gnu.org/software/gettext/manual/html_node/Maintainers.html#Maintainers
> 
> In the po/Makevars file, here is the XGETTEXT_OPTIONS when using
> glib/gi18n.h or glib/gi18n-lib.h:
> 
> XGETTEXT_OPTIONS = --from-code=UTF-8 --keyword=_ --keyword=N_ 
> --keyword=C_:1c,2 --keyword=NC_:1c,2 --keyword=g_dngettext:2,3

Also note that using "ide create-project -t empty foo" will create you a
new empty autotools project using pure-gettext. That might an easy way
to compare things. (It does require Builder from git).

-- Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Michael Catanzaro]

On Fri, 2016-04-22 at 09:54 +0100, Philip Withnall wrote:
> Upstream gettext and autopoint are the recommended tools to use,
> although you will need the latest versions of them in order to get
> support for all the things which intltool supports (namely, AppData,
> support for which was added in gettext 0.19.6).

We really need an intltool -> pure gettext transition guide, if anyone
feels up for taking that on, because it's not at all clear how this is
supposed to work.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gettext

[Philip Withnall]

On Fri, 2016-04-22 at 08:49 +0100, Patrick Welche wrote:
> All the docs for the maintainer side of i18n I found use intltool and
> glib-gettext, yet I see bugzilla bugs open to use upstream gettext /
> autopoint.
> 
> Do you have a description of The Right Way(tm)?

Upstream gettext and autopoint are the recommended tools to use,
although you will need the latest versions of them in order to get
support for all the things which intltool supports (namely, AppData,
support for which was added in gettext 0.19.6).

intltool and glib-gettext still work OK, but they are basically
unmaintained.

Philip

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GETTEXT message catalog placement

[Claude Paroz]

Le dimanche 22 avril 2007 à 02:18 +0100, Djihed Afifi a écrit :
 Hi,

Hi Djihed,

 We're still having a few problems to agree on a plural forms in Arabic,
 and I am trying to put together a test suit to test a number of plural
 forms. The code that I put together to do this is below.
 
 My understanding is that I have to:
 1- mkdir po, and create POTFILES.in with an entry for the file name
 2- run intltool-update --pot
 3- Translate file.
 4- put compiled file (msgfmt) in
 /home/djihed/dev/plurals/testcase/po/LL/LCMESSAGES/testbin.mo

The .mo files are being searched in multiple paths, but a common place
is /usr/share/locale/LL/LC_MESSAGES/
 
 5- run program with: LC_ALL=LL ./testbin
 
 (LL is a locale, such as ar)
 It fails to pick up the translated strings. I don't even know if it is
 finding the .mo file or not.

You can find out with using strace. Something like
strace -e open -o strace.log ./testbin
grep \.mo strace.log

You will then see if your .mo file is found, and where the program is
looking for .mo files.

 
 What am I doing wrong? I would appreciate any pointers.

Hope this helps.

Claude

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list