After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 531601 - Reference intltool in the docs, not ancient xgettext and friends
Reference intltool in the docs, not ancient xgettext and friends
Status: RESOLVED OBSOLETE
Product: java-gnome
Classification: Bindings
Component: General
4.0.x
Other Linux
: Normal normal
: ---
Assigned To: java-gnome bindings maintainers
java-gnome bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2008-05-05 18:31 UTC by Wouter Bolsterlee (uws)
Modified: 2020-11-06 22:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Wouter Bolsterlee (uws) 2008-05-05 18:31:48 UTC
The docs at

  http://java-gnome.sourceforge.net/4.0/doc/api/org/freedesktop/bindings/Internationalization.html

do not mention intltool. Using intltool is the recommended (actually, the only supported) way to do to translations for Gnome/GTK+ projects. Please expand or replace the section with some basic intltool usage instead of forcing people to do tedious and laborous work themselves using old, non-automated tools.
Comment 1 Andrew Cowie 2008-05-05 23:36:17 UTC
I thought that stuff was all a bit cumbersome. I'm glad to hear there is something different to use.

Vreixo, you wrote all that stuff originally. Have you used intltool? If so, do you want to fix it as Wouter suggests?

AfC
Comment 2 Vreixo Formoso 2008-05-06 08:52:31 UTC
I've tried intltool, but documentation continously refer to autoconf/automake. I haven't found any way to make intltool work without that. And I think java-gnome should not force applications to use a given build system. Moreover, autoconf/automake is, imho, not a good solution for java project.

I have make xgettext work for java files. No success with intltool. If somebody can address this issue it would be great, as intltool has great support for non-code-source files, such as .desktop files, glade files, etc...
Comment 3 Wouter Bolsterlee (uws) 2008-05-06 10:12:40 UTC
Intltool works without autotools as well. I use it e.g. in web projects written in PHP. The basic requirements are::

- setting up a Makefile (or the equivalent for other build systems) to:
  - compile .po files into .mo files
  - install the .mo files in the appropriate location
- a POTFILES.in and (optionally) a POTFILES.skip file in the po/ directory
- running intltool-update <LANG> (and -p the first time) in the po/ directory
Comment 4 Vreixo Formoso 2008-05-06 10:28:47 UTC
> Intltool works without autotools as well.

Great! Now the second step: how? is this documented? Do you know about any doc I can use to learn about how to use intltool without autoconf/automake? Are you sure I can do with intltool-update the same I can do with xgettext? Do intltool offer good support for Java language? Can you specify --keyword=_ --keyword=N_ as in xgettext - because we use _() with java, not the default gettext java support (very ugly)?

I'd like to use intltool in java-gnome. But I don't know how! I need documentation, I have search for it during weeks without success. I you can show me good tutorial, or even answer the questions I'll have, I can take the time to update java-gnome to use intltool. At this time, I think intltool won't work ok for us. I hope to be wrong.

Vreixo
Comment 5 Wouter Bolsterlee (uws) 2008-05-06 10:35:11 UTC
FYI, This is what I use for PHP (no autotools whatsoever):

http://bazaar.launchpad.net/~uws/anewt/anewt.uws/annotate/uws%40xs4all.nl-20080505212234-9y5s73m26iqigjks?file_id=i18n.make-20061228161338-qqfhbf8hswrejsey-1

Copy i18n.make to po/Makefile, create a i18n.conf with the name=value pairs grepped for at the top of the file and it already mostly works.

Note the hack to find all .php files. The propery way would be to have POTFILES.in written by humans, not automatically generated.
Comment 6 Vreixo Formoso 2008-05-06 11:18:27 UTC
> This is what I use for PHP (no autotools whatsoever):

mmm, looks ok. I will take a look.

> The propery way would be to have
> POTFILES.in written by humans, not automatically generated.

that is a thing I really don't like it too much... Java programs use to have lots of files, updating POTFILES.in by hand can be a pain. And that adds no value, as computer is good enought to search for strings marked with _()!! Is there any strong reason to force users to mantain POTFILES.in?

Vreixo
Comment 7 Wouter Bolsterlee (uws) 2008-05-06 11:21:07 UTC
(In reply to comment #6)
> > The proper way would be to have
> > POTFILES.in written by humans, not automatically generated.
> 
> that is a thing I really don't like it too much... Java programs use to have
> lots of files, updating POTFILES.in by hand can be a pain. And that adds no
> value, as computer is good enought to search for strings marked with _()!! Is
> there any strong reason to force users to mantain POTFILES.in?

Other than control over the process, I can't think of any. Oh, perhaps excluding deprecated files or e.g. svn:external includes.
Comment 8 Andrew Cowie 2008-08-15 04:45:13 UTC
No one worked on this. Bumping to 4.0.9

AfC
Comment 9 Vreixo Formoso 2008-08-15 04:48:59 UTC
I hope to take care of this in a pair of weeks. 4.0.9 is ok.
Comment 10 Andrew Cowie 2008-11-08 05:14:57 UTC
No one worked on this. Bumping to 4.0.10

AfC

Comment 11 Vreixo Formoso 2009-05-12 14:16:14 UTC
Ups, I completelly forgot about this. Given I have no time to huge contributions for now, I will address this. I promise it will be ready for next release.
Comment 12 André Klapper 2020-11-06 22:22:27 UTC
bugzilla.gnome.org is being replaced. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a recent version of java-gnome, then please feel free to report it at https://github.com/istathar/java-gnome/issues

Thank you for reporting this issue and we are sorry it could not be fixed.