Bug 529 - Make Scheme strings i18n-ized
Summary: Make Scheme strings i18n-ized
Status: RESOLVED FIXED
Alias: None
Product: UIM
Classification: Unclassified
Component: libuim (show other bugs)
Version: unspecified
Hardware: All All
: low enhancement
Assignee: YamaKen
QA Contact:
URL: http://lists.sourceforge.jp/mailman/a...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-21 16:16 UTC by YamaKen
Modified: 2006-12-28 13:26 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description YamaKen 2004-04-21 16:16:33 UTC
i18n-ized messages are required to provide description of customization items,
GUI labels, etc.
Comment 1 YamaKen 2004-09-30 05:49:04 UTC
Accomplished by r1368. But automatic update for po files is not yet available.

------------------------------------------------------------------------
r1368 | yamaken | 2004-09-30 15:55:13 +0900 (Thu, 30 Sep 2004) | 134 lines

* This commit enables proper gettext handling within Scheme world,
  adds locale object for Scheme, and adds an alternative
  implementation of uim_get_language_name_from_locale() written in
  Scheme

* Although the codes for Scheme gettext is sufficient, automatic
  update of po files involving scm files are not yet provided
Comment 2 TOKUNAGA Hiroyuki 2004-11-03 11:08:35 UTC
I found a solution, 'xgettext recognise .scm extension'.
See http://lists.gnu.org/archive/html/bug-gnu-utils/2004-08/msg00022.html

But even newest version of gettext doesn't supporting .scm yet, we should
use another solution for now.

My proposal is that copy all xxx.scm files to xxx.lisp, list up all xxx.lisp in
POTFILES.in.temp. This will need modification of intltoo-update.in, so this
means we couldn't use intltoolize in autogen.sh. But I think this is reasonable
temporary solution, what do you think?
Comment 3 YamaKen 2004-11-03 12:31:09 UTC
xgettext can extract the texts from *.scm. Try following command.

$ xgettext -LLisp -kN_ -k_ *.scm

The problem is not the extracting but the proper Makefile automation.
Comment 4 TOKUNAGA Hiroyuki 2004-11-05 14:37:06 UTC
> The problem is not the extracting but the proper Makefile automation.

What is "Makefile automation"?
Comment 5 YamaKen 2004-11-07 17:56:23 UTC
> What is "Makefile automation"?

Make 'make update-po' work involving *.scm in proper way.
And so on for any other Makefile targets.
Comment 6 TOKUNAGA Hiroyuki 2004-11-10 00:06:10 UTC
> Make 'make update-po' work involving *.scm in proper way.

This is possible with my proposal 'copy all xxx.scm files to xxx.lisp,
list up all xxx.lisp in POTFILES.in.temp.'

To confirm my proposal, check out revision 1627 and rerun ./configure script,
then try 'make update-po'.
Comment 7 YamaKen 2004-11-11 12:14:07 UTC
> > Make 'make update-po' work involving *.scm in proper way.
> 
> This is possible with my proposal 'copy all xxx.scm files to xxx.lisp,
> list up all xxx.lisp in POTFILES.in.temp.'

'in proper way' is my intention. Don't igonre it.

Although I don't know whether such way exists or not, I think that we should
record accurate information such as 'there is no proper way' or 'the proper way
may exist, but we choose the temporary solution' in this BTS item.
Comment 8 TOKUNAGA Hiroyuki 2004-11-12 03:33:40 UTC
Sorry, I missed 'proper way'.

Proper way is make xgettext correspond to .scm files. Next version of gettext
will correspond it, there's nothing we can except waiting new version.

Maybe intltool need modification, because intltool seems treating .scm files
specially.
Comment 9 YamaKen 2004-11-14 23:13:21 UTC
> Proper way is make xgettext correspond to .scm files. Next version of gettext
> will correspond it, there's nothing we can except waiting new version.
> 
> Maybe intltool need modification, because intltool seems treating .scm files
> specially.

I've understood well. Thank you for the detailed explanation and your work.
Comment 10 YamaKen 2006-12-28 13:26:56 UTC
The *.scm suffix problem is resolved by a small workaround in r4238, with
intltool 0.35.2.

And with libtoolize-related cleanup in r4236-r4251, the broken 'make distcheck'
problem has finally been resolved (although done with some dirty hacks).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.