well now it is "kinda" working
SkunkWorks: what are you trying to do on SF?
should we put a note on sf that the CVS has moved?
I think I can actually turn it off, let me try
Availability of CVS data will not be affected by this setting. If you have data in your project CVS repository and this service is disabled, CVS operations may still be performed; however, the "CVS" menu option on your project page will not be displayed.
sounds like a start
hey chris, that sounds like a smart move
maybe we should also change a key file or two so you can't accidentally build it thinking you have the latest
make ./configure error out?
how about removing configure?
or replace it with a simple bash script
printing an error message, and what to do to get the latest CVS
any of those sound good
#!/bin/sh \n echo "emc2 CVS has moved to ... see ... for more information" \n exit 1
yeah.. I can do that
give me 10 mins
I was just looking at the mail (dev/users)
SkunkWorks: care to tell us what you've seen?
I could not get there to begin with - "page cannot be displayed" now it is running slow but working.
I could just be me ;)
Truer words were never typed: <SkunkWorks> I could just be me ;
that is true for most of us
jepler: are you around?
alex_joni: just got back from lunch
* alex_joni has a nice topic for you
i18n, L10n and such
as you have done quite a good deal on AXIS, I was thinking you might share some tricks ;)
don't warn him, you should just ask before scaring him away
cradek: was thinking of asking nicely
but you were right.. I scared him away :((
well I don't know any "tricks".
what part are you asking about, specifically?
1. compiling .po files & installing them to the right spot
2. using gettext style translations from tcl, or how to sort the mess of $(LANG).msg
Python supports gettext-style .. I let tcl call the Python "_" function. It wouldn't work in a pure tcl application
-- MsgcatToPo Automatically converts msgcat-format files created with Extract_MsgCat to po-format.
cradek: that's the easy part
the problem is using the gettext stuff from tcl
I can't seem to find any example for doing that
A set of developer tools ('msgmerge', 'msgfmt') that check the
translations coming from the translators and convert them to the Tcl
.msg catalog format.
so we're still stuck with the .msg stuff
* alex_joni thinks about installing *.msg to /usr/share/locale/
I think it should go under "share" but I'm not sure it should go in locale/ since it's not in the mo format
jepler: in locale/ it should go into the proper LANG
but that's not appropiate for tcl
so I think share is also a good choice
but the mo should definately go to the default place, hope you don't mind if I take a peek at AXIS cvs how you do that..
tk puts their own here
ok, so we should do the same
cradek: it's tcl, what do you expect?
yeah,. whatever :)
this incredibly hard-to-understand piece of code is what sets the location for the .mo files:
i18n = [(os.path.join(LOCALEDIR,lang(f),"LC_MESSAGES"), [(f, "axis.mo")])
for f in glob("i18n/??.mo") + glob("i18n/??_??.mo")]
having to read it again, I'd say whoever wrote that should be shot, except it was me.
* alex_joni looks away
but laughs a crazy laugh first..
oh, and I didn't even show the definition for the 'lang' function
spare us :D
jepler: this should be simple stuff
too bad the people who develop this don't have a clue
which "this" do you mean?
pygettext & co even
I think I'm pretty clueless .. I just fumbled my way around 'till the messages started coming up in languages I couldn't read.
same here, except I could read the messages
cradek: still there?
small bug in the CIA log
I just commited a change to a few tcl files, but only the first 2 were reported
the others were in tcl/bin and tcl/scripts
err.. only in tcl/bin
4 more files..
it's not very important though.. just wanted to point it out
I also haven't seen the emc2/tcl/bin cia message yet
the other ones came through
it was on the same commit
doesn't matter, a separate one is sent for each directory
well.. only the first one was sent?
did you get any funny output from your cvs invocation?
no, all looked ok
I can paste if you like..
nah, that's ok if there was nothing there
probably cia rejected it because the * or ' made the xml invalid or something
hmm.. then why did it work the first time?
I'm no expert on that but it obviously makes it through my script ok (since it's fine in the email)
it worked for tcl/
oh good question
it didn't work for tcl/bin/
that must not be it
ahh heck, don't waste time on it :)
hrmm.. might have found a small bug on make install, can you confirm?
I see an empty dir called configs along with sample-configs gets created
it's in /usr/local/etc/emc2/ by default
any reason to still have that?
Unless they're inside a <TAG>, I don't think * or ' need to be quoted in xml
hrmm.. I just commited a change on Makefile.. didn't show in CIA either
cvs commit -m "installing tcl msgs to the proper place" Makefile
Checking in Makefile;
/cvs/emc2/src/Makefile,v <-- Makefile
new revision: 1.89; previous revision: 1.88
alex_joni: I made that directory on purpose
cradek: ok, didn't know what that was about.. was afraid it was forgotten from older times
that's where the system-wide configs can go
ok, never mind :)
just stumbled upon, and thought I'd better ask
we used to have configs in there..
jepler: need a bit of help on the build system
I want to compile the .po into .mo
so I added a src/po/Submakefile
then added po to the list of folders that Makefile searches for Submakefiles
OK sounds good so far
give me 1 more minute to check the Submakefile if it is ok
can I make it a Makefile temporarely and test using make ?
probably not, because each Submakefile has to be written as if it was executing from the top directory
(because it is)
I simply want a rule to call msgfmt -o
msgfmt -o $@ $<
but also a default I think?
or how does make know what %.po is ?
In make rules, "%" is a wildcard
so it could match de.po or po/de.po
so, po/%.mo: po/%.po ?
because % can match the character "/"
I see.. so simply like that?
yeah I think so
make doesn't call it..
have you made the default target depend on the .mo files?
just because make can make a target doesn't mean it does
something like: userspace: $(patsubst %.po, %.mo, $(wildcard po/*.po))
that will make the 'userspace' target depend on each mo file that could be made from the .po files in po/
ok, anywhere in the Makefile ?
or TARGETS += $(patsubst ...)
I'm not sure why I have TARGETS, frankly
ahh,, that makes more sense to me :)
I'll do that
there was some reason but now I've forgotten it
heh, now there is a de_rs274_err.mo
but it's still text ? is that normal?
hrmm.. seems like it
no, .mo is a binary format
then probably my editor knows how to convert :D
* alex_joni uses mc & mcedit
ok, less shows it as binary
cradek: CIA is not working anymore.. second commit which doesn't show up
alex_joni: You should add a rule to put the .mo files in the correct location for run-in-place, and put those filenames in TARGETS
../share/tcl/msgs/%.mo: po/%.mo ; cp $< $@
something like that
and not tcl/msgs I guess
Apr 10 14:41:21 cvs sm-mta: k3AJfKKq084233: to=<firstname.lastname@example.org>, ctladdr=<email@example.com> (1002/1002), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30562, relay=cia.navi.cx. [220.127.116.11], dsn=2.0.0, stat=Sent (Ok: queued as 03BE31D8010)
alex_joni: I don't think the problem is on my end. It'll probably start working again.
yep CIA just fell off and then rejoined
jepler: the .mo are not tcl related
jepler: .mo and .po are standard gettext, and used in the interp
they only work if they get copied to /usr/share/locale/$(LANG)/...
at least if I'm getting this right..
they should only be copied to $(prefix)/share/... for run installed
they should be copied to some other location for run-in-place
and it's that location that should be listed in TARGETS
not sure if gettext can read the from some other location
python's gettext can
how do you specify that?
in "C" you make a call to bindtextdomain(). One of the arguments is a directory name.
what about leaving them in src/po ?
why is that a bad choice?
my gut tells me that it doesn't make sense for any file in src/ to be required to run emc
gettext.install("axis", localedir=os.path.join(BASE, "share", "locale"), unicode=True)
^^ this is how Python gets the .mo files from the right location. BASE is set based on the full path to the axis script
so it's is /usr/bin/axis, then BASE is /usr and it gets messages from /usr/share/locale
I don't think rip & locale is 100% necessary
it only complicates stuff unnecessaryly
hmmm.. I see no bindtextdomain() call at all
I've never actually used the C gettext API
there is a define _(string) gettext(string)
so that might actually work
If all the source code knows how to find files relative to $(prefix), then making it work for RIP is just a matter of treating the top dir as $(prefix) and copying files to the right place
yes and no, because there are different dirs for rip and install
but I agree this can be handled somehow cleverly
If rip is good for developers, then it's good for "developers" of the message catalogs
maybe from config.h ?
have the location there, and only include it to the bindtextdomain() call
of course the location put there by configure
based on RIP or installed
my point is to make the RIP directory structure enough like the installed one so that no extra C code is needed to make the message catalogs work for RIP too
just an extra bit in the makefile
then I need $(emc2_topdir)/share/locale/de/LC_MESSAGES ?
as a place where to install the .mo ?
and I still need to get $(prefix) into the C code
you need to get $(prefix) in the C code no matter what
ok, just wanted to make sure we're talking about the same thing here :)
I need to digest this a bit better :(
wonder if I shoudl commit the version I have now, then do what you say later
sure, why not
already done it ;-)
think I'll head to bed early tonight (11:30PM now)
good night all
if your changes work I might release tonight
I only made changes to HEAD
should I move them over?
if they are ok, I'll move to the branch
or you can..
but who tests them?
I would I guess, it's a simple matter to try it
yeah.. guess so