Re: Strings again

> > The other topic that needs discussion is translation with the _"xxx" i18n
> > translation strings at  http://prothon.org/wiki?pagename=TranslationStrings.
> > I think we should have these but only Lenard and I have discussed them.


[I apologise for only seeing now that you did have a discussion about strings
 (including calling some of my statements absurd :-)  I realise this
 may be opening old wounds but I hope I can explain this stuff in
 a clearer way now that some time has passed.  I don't expect anyone
 to do anything other than dismiss it all, and perhaps some people
 looking back on it in several years time ruefully.]

I just want to make it clear that a scheme such as _() or equivalents
only does a tiny part of the job.  In particular you have to also deal
with the issue that order of formatting changes.  As a simple example
you may say this in english:

  "%d of %d items imported" % (current, total)

Whereas in another language it would be written the other way round:

  "jkjh dfgd %d gfdg %d" % (total, current)

The latter is common in Japanese.

The above can't be simply resolved by looking up the format string.
(Yes, you could supply dicts and other stuff but people don't and
before you know it, your standard library is full of stuff that
can't be internationalised/localised).

What I was suggesting was that the code looks as close as possible
to this:

   print MAGIC, current, total

And behind the scenes the lookup happens (with defaults or whatever).
But that also allows you to suddenly do a lot better.  For example
shouldn't I trivially be able to make it output in XML or HTML
or whatever format is common next year without having to write
seperate code for each output format?  MAGIC would just "do the
right thing" including doing the right output format, as well
as deal with the localisation issues.  The reason for making it
compulsory would be to ensure that all code does the outputting
"correctly".

The locale issues arise because of how Unicode works.  Imagine
someone said that the letter "a" looks the same in US English
and British English and hence it is the same letter and has one
Unicode codepoint for it.  But what if it really meant different
things in the languages.  If you didn't have the locale information,
you would not be able to tell who it belonged to which will cause
issues later.  Unicode actually did do this, especially to the
CJK languages.

And if you think there is no difference between British and American
English, then look at symbols where that has already happened.  For
example the # symbol means something very different.

If you have ever written and had to convert code to be internationalised
or localised or in a different format (XML, HTML etc) you will notice
just how hard it is.  The languages all make it hard because that is
all done as an afterthought, and programmers have to call byzantine
libraries.  Most just end up nothing bothering.

Having _ near hard coded strings doesn't come close to addressing
the big picture.

Here is the true test.  Take a sample "Hello World" program
and also have it output todays date, and how many days of the
month have passed as a percentage.

How much extra effort (just on the coding side) is it to also
output in German?  Japanese? Hebrew? Arabic?  HTML?  XML?
teletype?

For the next generation of languages I believe the answer
is going to be "none".

Roger