I prefer first not having localization, then your proposed Str solution,
then the existing solution.

Original Message:
-----------------
From: Istvan Varga istvan@csounds.com
Date: Tue, 01 Feb 2005 12:42:21 +0100
To: csound-devel@lists.sourceforge.net
Subject: Re: getstring (was: [Cs-dev] Changes submitted to CVS)


Anthony Kozar wrote:

> I have mixed feelings about this.  I certainly have not been good about
> creating new strings when I am modifying code.

Having eliminated the index number, you only need to enclose the string
with Str(), e.g. Str("blah"). If there is a translation for the string
literal "blah", then it will be translated; if not, then it will just
remain as it is. The disadvantage is that you need to be more careful
about typos, although the only adverse effect of a mistyped string is
that it will not be translated. You can also easily provide your own
translations for a plugin (or others can contribute), without the need
for a central authority to assign index numbers. The new system will
load all database files of the selected language from the directory
defined by CSSTRNGS, and any string that has been found in a database
will be translated.

> But then there are definitely some theoretical benefits to the system.
 > (Despite being someone who only speaks English, I don't expect that the
 > rest of the world should have to :)

I did not suggest to remove localization support (although I pointed out
some advantages of doing so), only asked for opinions about three possible
solutions. So far, I got two votes for removing support for multiple
languages (by Michael Gogins and Victor Lazzarini), you apparently prefer
the original getstring by John ffitch (although I am not sure), and finally
I would choose to either remove getstring or use the new one. Overall, the
idea of removing getstring seems to be most popular, but more posts on this
subject are needed, as a total of 4 answers may not be enough to make a
decision.

> But I do want to avoid the confusion of having external string databases
and
> users not knowing which database goes with which version of Csound.
> (Currently on MacOS 9, the strings are integrated into the application's
> resource fork.  One of the advantages of this is being able to have
multiple
> versions of Csound in the same folder while keeping their string databases
> separate).

The new system has a fixed, portable string database format. You can create
a
database now (documentation on the format has been posted), and use it on
any
future version of Csound - assuming that the code is not removed - on any
platform. Additionally, .xmg files of the old (number indexed) format are
simply ignored, and do not cause any problem.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net