[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Is l10n a little off?
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] Is l10n a little off? |
Date: |
Sun, 15 Jan 2006 02:07:41 -0800 |
User-agent: |
Mutt/1.5.9i |
On Sun, Jan 15, 2006 at 10:20:52AM +0100, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Sat, 14 Jan 2006 18:25:57 -0800, Nathaniel
> Smith <address@hidden> said:
> njs> It isn't checked in to the source tree, and the versions in
> njs> distributed tarballs are really bad, because of they were
> njs> generated without the fixes that I just made in the last few
> njs> days.
>
> So you're saying I should really remove it and have it regenerated, is
> that it? Seems to me there's a lack of proper dependency then...
> $(DOMAIN).pot-update depends on $(POTFILES), which is generated from
> po/POTFILES, but it looks like POTFILES.in hasn't been properly
> updated, I see quite a lack of file names in it.
I'm saying whatever you have seems not to be up to date. I don't know
if that's because you haven't regenerated it, or what... actually, I
don't even know how to ask the makefile machinery in there to do
an update, I just know that every once in a while ('make dist',
mostly) make decides to regenerate the .po files -- and then I have to
revert them, because the translators get annoyed at me if I touch
those files :-).
How POTFILES.in is supposed to work also confuses me. intltool-update
--maintain says it can't find any missing files, so I've sort of been
hoping that things will just work out somehow. Or at least figuring
that if there really is a problem, it can wait until a translator
finds strings missing.
> BTW, I've noticed that in my working directory, a lot of entries in
> po/fr.po have been commented away... Uh-oh, and I see that I've quite
> a diff in those files compared to the mainline (lucky I'm careful with
> what I commit, eh? :-) I'll get back about commits, BTW). I guess
> I'd better regenerate that template.
Yeah, be careful not to commit any po files you don't mean to.
> Reading that page, it seems to me like the location doesn't have to be
> just one unique place per system, it only has to be exactly what's
> compiled into the application. So basically, as long as PACKAGE and
> LOCALEDIR are correct when being used with bindtextdomain()
> (monotone.cc:245), everything should work right. And it should, since
> LOCALEDIR is derived from $(localedir) in Makefile, which is
> $(datadir)/locale.
Sounds plausible. If you want to add a configure option or whatever
(environment variable, maybe?) to change the locale dir for testing,
go for it :-).
> njs> You also have to make sure your locales are properly generated;
> njs> this is somewhat complicated and I don't really understand it,
> njs> but it's per-system per-locale -- so if you can convince "ls" or
> njs> "gcc" or whatever to give you errors in Swedish, then this part
> njs> is working and you don't need to worry about it.
>
> That's not a problem, that part works like a charm:
>
> : ; ls -l po/monotone.pot
> -rw-r--r-- 1 levitte levitte 4016 2006-01-11 20:04 po/monotone.pot
>
> And a 'monotone-0.26pre1 pull' gives my numbers with a space inserted
> every third digit in the integer half and a comma as a fraction
> delimiter instead of a period.
Hmm, neither of these is really evidence, I think? The question is
whether your system has the sv locale enabled or not. (Which is a
separate question from whether your system has any other locale
enabled, and also a separate question from whether you have requested
the use of the sv locale as a user.)
The way to test is do something like:
$ LANG=sv ls -z
and see if both lines of output are localized to swedish.
> njs> The gettext stuff should be working in current mainline.
>
> I'll make an extra check to see if POTFILES.in should be updated.
Cool.
-- Nathaniel
--
Damn the Solar System. Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
-- Lord Jeffrey