tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: Translations strings in CVS

[<lau...@uf...>]

On 11 Jul, Giorgos Petasis wrote:
>> As for the Hellenic, I just want to check to make sure that got
>> imported correctly.  The best thing about using \u00xx is that
>> it can't get garbled in something that doesn't understand high
>> bit chars.
> This is logical, although I suspect that tcl can understand them :-)
> And for those who don't know how to create these \u sequences, is
> there a simple procedure in tcl in order to translate them?
> 

Did you try Jan's utility? Does that work? My understanding is that if you
save stuff in the Unicode format, you're no supposed to have all the
conversion problems that you find when using UTF-8. But then, I'm new at
this.

> Sorry for the incovinience,
> 

It's no problem. We'll eventually get all of this right but it might take a
misstep or two along the way.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: RE: Translations strings in CVS

[Giorgos P. <pe...@ii...>]

In Äåõ, 10 Éïýë 2000, Jeffrey Hobbs wrote:
> Hellenic (el.msg) comes across in something
> that I can't view correctly on Windows or Unix (I do have
> bitstream cyberbit on Windows, but no specific Greek font).
I suppose I am the only one who used UTF-8 to encode the messages :-)
The file I sent was encoding using utf-8. I really cannot understand why to
use strange alternative ways in order to specify messages. My opinion is that
the message catalog should encode all its messages in utf-8 and use this encoding
when sourcing the files. Any way, I am willing to translate them into whatever
you want :-). 
Also, Laurent told me that he also had problems opening the files.
I attach the file again, this time is zipped with gzip.

> As for the Hellenic, I just want to check to make sure that got
> imported correctly.  The best thing about using \u00xx is that
> it can't get garbled in something that doesn't understand high
> bit chars.
This is logical, although I suspect that tcl can understand them :-)
And for those who don't know how to create these \u sequences, is
there a simple procedure in tcl in order to translate them?

Sorry for the incovinience,

George

[TCLCORE] Re: Translations strings in CVS

[Andreas K. <a.k...@we...>]

 
> Jeffrey Hobbs wrote:
> > My thoughts... I think local languages should attempt to truly
> > localize.  This may work best the way the Spanish msgs are done -
> > (as well as French) in that \u00xx is used for high bit encodings.
> > I think the German (and partly the Dutch) messages should use
> > umlauted chars and the S-sharp where appropriate (or does MS avoid
> > this as well?).

> > As for the Hellenic, I just want to check to make sure that got
> > imported correctly.  The best thing about using \u00xx is that
> > it can't get garbled in something that doesn't understand high
> > bit chars.

> > George - please verify (by checking the file back out of 8.4
> > CVS and trying it) that this didn't get garbled.
 
> I already noted this as well, and all I can say is that I fully
> agree with you.
 
> Attached is a small utility that can do the correction. Just try:
>       msgcv el.msg cp1253
>       msgcv ja.msg euc-jp

> and the result is two new files "el.msg.out" and "ja.msg.out"
> using the '\uXXXX' convention. It should be easy to apply
> this to the message files in CVS now. For german, the umlaut-
> correction should be done manually first.

I agree and will do it (Now that I know the umlaut-codes (:- Wiki)).


-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

Re: Translations strings in CVS

[Jan N. <j.n...@ch...>]

Jeffrey Hobbs wrote:
> My thoughts... I think local languages should attempt to truly
> localize.  This may work best the way the Spanish msgs are done -
> (as well as French) in that \u00xx is used for high bit encodings.
> I think the German (and partly the Dutch) messages should use
> umlauted chars and the S-sharp where appropriate (or does MS avoid
> this as well?).
> 
> As for the Hellenic, I just want to check to make sure that got
> imported correctly.  The best thing about using \u00xx is that
> it can't get garbled in something that doesn't understand high
> bit chars.
> 
> George - please verify (by checking the file back out of 8.4
> CVS and trying it) that this didn't get garbled.

I already noted this as well, and all I can say is that I fully
agree with you.

Attached is a small utility that can do the correction. Just try:
      msgcv el.msg cp1253
      msgcv ja.msg euc-jp
and the result is two new files "el.msg.out" and "ja.msg.out"
using the '\uXXXX' convention. It should be easy to apply
this to the message files in CVS now. For german, the umlaut-
correction should be done manually first. The Dutch translation
is already in the correct format ;-)

Regards,
-- 
Jan Nijtmans, CMG Oost-Nederland B.V.
email: j.n...@ch... (private)
       jan...@cm...  (work)
url:   http://purl.oclc.org/net/nijtmans/

Re: RE: Translations strings in CVS

[<ldu...@uf...>]

> I was just reviewing the msg catalog translation strings, and I had
> some questions.
> 
> There seems to be different methods used for encoding the files.
> The Spanish msgs use the \u00xx for extended chars, whereas the
> German msgs avoid them by using the lower ascii expansion
> (&uumlaut; == ue).  Hellenic (el.msg) comes across in something
> that I can't view correctly on Windows or Unix (I do have
> bitstream cyberbit on Windows, but no specific Greek font).
> 

I think it because not everyone used the same tools to create the
message catalogue. I used MSGEdit, I think a few others did too (most
likely, the ones that came out with \u00xx). Some used standard editors
which did the output however they felt was best.

> I know this was somewhat discussed, but it looks like no certain
> resolution was imposed.
> 

Uhm... imposed, no. Suggested, yes. I think George had said that the
files he had couldn't be read by the msgcat utility. So he did it how
best he could.

Jan sent us a note today saying he has a little utility that possibly
fixes the problem with George's file. If it does, George will hopefully
be able to send you another version of his translations.

L

Re: Translations strings in CVS

[Andreas K. <a.k...@we...>]

--------; charset=us-ascii
 
> Jeffrey Hobbs wrote:
> > My thoughts... I think local languages should attempt to truly
> > localize.  This may work best the way the Spanish msgs are done -
> > (as well as French) in that \u00xx is used for high bit encodings.
> > I think the German (and partly the Dutch) messages should use
> > umlauted chars and the S-sharp where appropriate (or does MS avoid
> > this as well?).

> > As for the Hellenic, I just want to check to make sure that got
> > imported correctly.  The best thing about using \u00xx is that
> > it can't get garbled in something that doesn't understand high
> > bit chars.

> > George - please verify (by checking the file back out of 8.4
> > CVS and trying it) that this didn't get garbled.
 
> I already noted this as well, and all I can say is that I fully
> agree with you.
 
> Attached is a small utility that can do the correction. Just try:
>       msgcv el.msg cp1253
>       msgcv ja.msg euc-jp

> and the result is two new files "el.msg.out" and "ja.msg.out"
> using the '\uXXXX' convention. It should be easy to apply
> this to the message files in CVS now. For german, the umlaut-
> correction should be done manually first.

I agree and will do it (Now that I know the umlaut-codes (:- Wiki)).


-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

RE: Translations strings in CVS

[Jeffrey H. <jef...@aj...>]

I was just reviewing the msg catalog translation strings, and I had
some questions.

There seems to be different methods used for encoding the files.
The Spanish msgs use the \u00xx for extended chars, whereas the
German msgs avoid them by using the lower ascii expansion
(&uumlaut; == ue).  Hellenic (el.msg) comes across in something
that I can't view correctly on Windows or Unix (I do have
bitstream cyberbit on Windows, but no specific Greek font).

I know this was somewhat discussed, but it looks like no certain
resolution was imposed.

My thoughts... I think local languages should attempt to truly
localize.  This may work best the way the Spanish msgs are done -
(as well as French) in that \u00xx is used for high bit encodings.
I think the German (and partly the Dutch) messages should use
umlauted chars and the S-sharp where appropriate (or does MS avoid
this as well?).

As for the Hellenic, I just want to check to make sure that got
imported correctly.  The best thing about using \u00xx is that
it can't get garbled in something that doesn't understand high
bit chars.

George - please verify (by checking the file back out of 8.4
CVS and trying it) that this didn't get garbled.

Thanks,

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

[TCLCORE] Re: FW: Q about managing open source development

[Jeffrey H. <jef...@aj...>]

I thought I should share this with everyone on the core list as
we start considering how to open this process up.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

-----Original Message-----
From: Jeffrey A Law [mailto:la...@cy...]
Sent: Monday, July 10, 2000 11:54 AM
To: Jeffrey Hobbs
Subject: Re: Q about managing open source development




  In message <NDB...@aj...>you
 write:
  > I got your name from Jim Ingham, who noted that you'd be a good person
  > to ask about experiences related to managing an open software development
  > effort (gcc).
As good as any I suppose :-)

  > I'm currently the lead maintainer and manager of Tcl/Tk,
  > but I've also been imbued with the responsibility by John Ousterhout
  > (the original author and CTO of Ajuba) to foster better community
  > involvement in the development.
Understood.

  > Tcl/Tk has always been open source and
  > invited people to hack on it, but in general the core parts have been
  > fairly strictly controlled over its lifetime (you could say it lies in
  > the Cathedral).  So my job is to move it more towards the Bazaar, while
  > trying to avoid the disadvantages of that development model.
Right.  That's the 'trick' of course -- to reap the benefits of a Bazaar
model without the code turning into a mess of spaghetti code.

  > The main ideas that have come up are opening direct CVS write access
  > to more people (it's already in public NetCVS), and creating a
  > steering committee.
Sound like the right steps.  The first (hopefully) leads to more active
participation from developers and a wider team of "core" contributors that
everyone trusts to do the right thing.

That's one of the key things you want to build up -- a larger group of
folks that you trust to do the right thing and to whom you can delegate
tasks (or better yet, they just pick them up because they need to be done).

That's also the first big pitfall -- get the wrong group of core folks and
you end up with a mess of code or personality conflicts that rip the project
apart (witness the *bsd* splinters over the years).

The other big pitfall is just learning to trust a wider range of folks and
even if you disagree with them sometimes to realize that if you can't design
and implement a better solution (usually due to time constraints), then
sometimes you have to let them go in a direction that maybe you wouldn't.

  > I noticed that the gcc steering committee was
  > formed of people "to represent the interests of [different] communities".
  > Did this prove to work well?  I am currently making the decision on
  > who should be considered for the steering committee (or on what basis).
This was both a practical and political move -- people have been more
comfortable knowing that it wasn't just Cygnus (or me) calling the shots.
It's been extremely valuable in dealing with RMS and some conspiracy theory
folks.

But is was also a very practical move -- in the past GCC had been controlled
by two people (RMS on the policial side, Kenner on the development side) and
experience had shown us that that model simply wasn't working and we had to
try something different.

So we contacted a group of folks, not necessarily all developers, that had
a long term interest in seeing GCC succeed and who were well respected
in different communities that used GCC.   The steering committee basically
deals with political issues, not technical ones (which we leave in the hands
of the developers, where it belongs).  We've been very happy with the results.

Overall, the biggest thing I've found is if you make the developers happy,
they'll want to contribute more time/energy.  That in turn allows the project
to grow.  If the developers are unhappy, then you have to find out why and
rectify the problem.

  > I'd appreciate it if you could share with me any insight on what to
  > watch out for, based on your experience, as I move forward with this.
  > Perhaps also what you would have done differently.
I (personally) would not have gotten buddy-buddy with RMS again, it's been
a major headache, but I was outvoted on that particular issue.  The lesson
is be very careful who you bring into the political decision process; people
who are not willing to compromise for the overall good of the project are
generally bad choices :-)

Good luck,
jeff


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: QT Developer Interview

[Jeffrey H. <jef...@aj...>]

I got this off slashdot.  It's part 4 of an interview with one of
the Qt Toolkit developers.  I picked this part, because it is where
he discusses (just shortly), his experiences with distributed
development in the Qt project:
	http://www.beopen.com/features/interviews/wallison_part4.html

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Final MSGedit fixes

[Jan N. <j.n...@ch...>]

lau...@uf... wrote:
> http://www.tu-harburg.de/~skfcz/msgedit.tar.gz
> 
> There is a bug with the program, though: some of the strings contain "\n"'s
> and msgedit saves these strings as "\\n". The saved files will need to be
> edited to correct this problem.

Here is, finally, the fix for the described problem. Just apply this
patch to the standard MSGedit distribution and everything should be O.K.

The cause of this problem was a wrong ordering of substitutions before
saving the string. The result was that in the case of '\n' the
backslash was doubled. Performing the double-backslash substitution
before the '\n'-substitution fixes everything.

Regards, 
-- 
Jan Nijtmans, CMG Oost-Nederland B.V.
email: j.n...@ch... (private)
       jan...@cm...  (work)
url:   http://purl.oclc.org/net/nijtmans/

[TCLCORE] Re: Final MSGedit fixes

[<ldu...@sp...>]

On  8 Jul, Jan Nijtmans wrote:
> Here is, finally, the fix for the described problem. Just apply this
> patch to the standard MSGedit distribution and everything should be O.K.
> 

I thank thee, sire. :-)

L



--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Words to consider...

[Eric M. <er...@aj...>]

I'm sure this is irritating everybody else almost as much as it is me.
Sorry.

Testing the list server "Re: [TCLCORE]" sprocket (attempt #8).

- eric

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Words to

[Eric M. <er...@aj...>]

Testing the list server "Re: [TCLCORE]" sprocket (attempt #7).

- eric

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Words

[Eric M. <er...@aj...>]

Testing the list server "Re: [TCLCORE]" sprocket (attempt #6).

- eric

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Words

[Eric M. <er...@aj...>]

Testing the list server "Re: [TCLCORE]" sprocket (attempt #5).

- eric

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: [TCLCORE] Words to consider...

[Eric M. <er...@aj...>]

Testing the list server "Re: [TCLCORE]" sprocket (attempt #5).

- eric

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] [TCLCORE] Re: [TCLCORE] Re: [TCLCORE] Re: [TCLCORE] Words to consider...

[Eric M. <er...@aj...>]

Testing the list server "Re: [TCLCORE]" sprocket (attempt #4).

- eric

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: [TCLCORE] Re: [TCLCORE] Words to consider...

[Jim I. <ji...@ap...>]

Also sprach Scott Stanton:

> 
> Jim Ingham said:
>> Gcc,
>> (starting with the egcs fork) put a lot of effort into setting up a
> steering
>> committee that contained both developers and users, and was not
> dominated by
>> any one interest.  Then they maintain a parallel, technical review
> structure
>> that maintains code quality through a system of area maintainers and
> careful
>> submission & review practices to assure that (a) submitted code is in
> line
>> both with the gcc design principles, and future goals and (b) the
> knowledge
>> of same are transmitted from one generation of gcc hackers to the next.
>> They have also documented these practices clearly, with Hack rules and
> well
>> defined maintainers lists, and supported them with a nice CVS
> repository,
>> and mailing lists for patches and general discussion...
> 
> Are these documents readily available somewhere?  It seems like they'd
> make for interesting reading as we try to set up similar structures for
> Tcl development.
> 

First off, you should have a look at gcc.gnu.org, which is the official
version of the old cygnus egcs site.  They have some nice stuff there.  The
Maintainers list and the hack rules are in the gcc sources.

Also, it might be good to contact the egcs folks - maybe Jeff Law would be a
good person to try, or Jim Wilson.  They are pretty dedicated to open source
development, and also have had a lot of experience both with the more closed
development of the old gcc, and with setting up a more open community in the
face of this other development model.  If you had some idea of what you
wanted to do, they would probably be willing to give you some good feedback
on it.  I know in particular that Jeff is not shy of expressing his
opinions, and he is a good guy to talk with.

Jim
-- 
Jim Ingham                                 ji...@ap...
Apple Computer

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: [TCLCORE] Re: [TCLCORE] Re: [TCLCORE] Words to consider...

[Eric M. <er...@aj...>]

Testing the list server "Re: [TCLCORE]" sprocket (attempt #3).

- eric



--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE]

[Eric M. <er...@aj...>]

Testing the list server "Re: [TCLCORE]" sprocket (attempt #2).

- eric


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE]

[Eric M. <er...@aj...>]

Testing the list server "Re: [TCLCORE]" sprocket.

- eric

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: [TCLCORE] Re: [TCLCORE] Words to consider...

[Scott S. <st...@aj...>]

Jim Ingham said:
 > Gcc,
 > (starting with the egcs fork) put a lot of effort into setting up a 
steering
 > committee that contained both developers and users, and was not 
dominated by
 > any one interest.  Then they maintain a parallel, technical review 
structure
 > that maintains code quality through a system of area maintainers and 
careful
 > submission & review practices to assure that (a) submitted code is in 
line
 > both with the gcc design principles, and future goals and (b) the 
knowledge
 > of same are transmitted from one generation of gcc hackers to the next.
 > They have also documented these practices clearly, with Hack rules and 
well
 > defined maintainers lists, and supported them with a nice CVS 
repository,
 > and mailing lists for patches and general discussion...

Are these documents readily available somewhere?  It seems like they'd 
make for interesting reading as we try to set up similar structures for 
Tcl development.

--Scott


--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: [TCLCORE] Words to consider...

[Jim I. <ji...@ap...>]

Also sprach Jeffrey Hobbs:

> I found this on Slashdot (The Cathedral and The Bizarre), which
> is based on this article:
> http://www.macopinion.com/columns/macskeptic/00/07/07/index.html
> 
> The whole thing is well worth reading, but I'm excerpting some juicy
> bits to ponder:
> 

There are two points here that I want to address.  One is the bit about
incompatible changes in Perl4->5.  That was a big change in the language,
they were adding a lot more structure, and if it was necessary to break a
few older scripts, then maybe that was not such a bad thing.  Perl kind of
sabotages itself in this regard, because it allows so many ways of
expressing the same thing that I imagine it is pretty hard to change things,
and support ALL possible ways to write Perl code.  The Perl code that I
wrote for NASA went from 4->5 no problem, however, so...  I don't think that
this is a relevant argument for or against OpenSource in the long run...

However, the more important point is that there you can't just open the
doors to all comers, and allow coherent software to come out of it.  But
this is not a new observation, and there are successful long-term software
projects that have found ways around this.  Gcc is one example, and recently
gdb is another.  Both are starting from fairly crusty inherited source
bases, with long histories and LOTS of users from all walks of life.  Gcc,
(starting with the egcs fork) put a lot of effort into setting up a steering
committee that contained both developers and users, and was not dominated by
any one interest.  Then they maintain a parallel, technical review structure
that maintains code quality through a system of area maintainers and careful
submission & review practices to assure that (a) submitted code is in line
both with the gcc design principles, and future goals and (b) the knowledge
of same are transmitted from one generation of gcc hackers to the next.
They have also documented these practices clearly, with Hack rules and well
defined maintainers lists, and supported them with a nice CVS repository,
and mailing lists for patches and general discussion...

Sorry to go on so long, but the main point is that there are good models for
doing open source development that don't fall into the trap of having the
maintainers try to do too much, and thus always fall behind community
expectations, and not take full advantage of the community; and a too open
system that makes the software inconsistent and ugly...

Jim


-- 
Jim Ingham                                 ji...@ap...
Apple Computer

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Words to consider...

[Jeffrey H. <jef...@aj...>]

I found this on Slashdot (The Cathedral and The Bizarre), which
is based on this article:
	http://www.macopinion.com/columns/macskeptic/00/07/07/index.html

The whole thing is well worth reading, but I'm excerpting some juicy
bits to ponder:

....
Programmers - at least the kind who are likely to get
involved in OpenSource project - are a notoriously independent lot.
They love to do their own thing and always think they have a better
way to do things.

Normally, this is an advantage because, with filtering and discipline,
this is from whence the fountain of creativity which drives this
industry comes. Unchecked and unfiltered, though, and you have
unbridled chaos. As a result, you have no less than six different
desktop systems and two different configuration systems and tools
whose command line options change not only from system flavour -
but from revision to revision. Perl is the best example of this - when
they went to version five, they changed the language syntax in a way
which broke existing code. Perl itself is a testimony to the
OpenSource mindset - it's a gruesome mishmash of inconsistent
syntax and function calls - definitely a product designed by
committee - but one wherein each member clearly wasn't listening to
anyone else.

Raymond touts the stability of Linux as proof of the OpenSource
concept, but that's a bit misleading. The core of Linux was written
by one person - Linus Torvalds. Moreover, there is a small group
who shepherds the contributions to the kernel to keep it stable and
clean. In other words, there's a priesthood at the top of the bazaar.
If you check into each successful OpenSource project, you see the
same thing: a small group of referees who filter the input and weed
out the bad ideas. The bazaar has cops. The chaos is contained.
....
....
People jump on the bandwagon and promote the software, and the
crowd grows and grows - often way out of proportion to the quality
of the solution. Perl, again, is an excellent example of this. It's really
a terrible language - badly.. ok... not designed, clumsy and
arbitrary. But it works - is better than shell scripting, and more
powerful than awk... and it was the first serious attempt at such a
language. So it went platinum with a bullet.
....
....
Ironically, when commercial developers release applications which
are clearly not 100%, we accuse them of forcing the customer to be
beta testers, but in a sense, OpenSource assumes you're not only
going to be a tester; you're going to be a programmer and fix the
bug!
....

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Re: Translations strings in CVS

[Giorgos P. <pe...@ii...>]

In Ðåì, 06 Éïýë 2000, lau...@uf... wrote:
> On  6 Jul, Giorgos Petasis wrote:
> > Hi Laurent,
> > 
> > I have done the greek translation and I have attached the file.
> > The file is encoded in utf-8 encoding, as you suggested.
> > 
> > On equestion remains though: Have you patched message catalogs
> > to read things in utf-8 encoding by default?
> > Because this file if simply sourced won't work.
> > Have i done anything wrong?
> > 
> 
> I don't know. Like I said before, I've never touched anythig other than ISO
> 8859-1 (latin 1). Can you resend the file zippped (or gzipped, whatever) and
> copy tc...@aj...? My MUA seems to think it's a text file but
> that may mess things up when I save.
> 
> I'll try to test the loading and stuff later.

Ok, I have gzipped the file and attached it to this mail.
The message file is in utf-8 encoding.

My opinion is that the whole message catalog
facility has to store its messages only in this format. I see no point in
doing a simple source of the file that contains the messages and leave
the code inside this file to do the necessary conversions.
Instead if we decide that files are sourced with a default encoding (a feature which
I think will be in next release, source -encoding), then there will be no need for
conversions. In order to use the message catalog as is right now, I have to place
a "encoding convertfrom iso8859-7..." in front of every (!) string.
And I am not sure if this would not depend on the system encoding...

George