The localization problem is a complex problem. Indeed, any big database
system _should_ implement it. And yes, it can be implemented in sqlite,
and it can be activated through a PRAGMA directive. But implementing it
into sqlite (localization is not limited to numbers) would increase the
size of the code, defeating the purpose of having a database with a very
small memory footprint. Thus, probably the best solution is to have a
standard internal representation (U.S. standard I think is fine,
especially that Dr. Hipp is from U.S.) and a different presentation
implemented through an optional extension, an extension that wouldn't be
carried over by ALL sqlite users.
On Tue, 31 Jan 2006, Bert Verhees wrote:
Will Leshner wrote:
On Jan 31, 2006, at 1:42 PM, Bert Verhees wrote:
It is only the English speaking part of the world using Arabic numerals
is a '.',
And the Japanese speaking world :)
Yuo are right, and the South American speaking Spanish also
But the South American speaking Portuguese not, the Russian not.
The Chinese, I could not check on my Windows.
Maybe it is fifty-fifty
A pragma taking care for this could help, but, for me I have written my own
functions, doing the translation well, it is not an issue.
Like Boguslaw, I use Delphi, I use a function like this, I am used to that,
for many years, with many databases.
Decimalseperator is only a variable in the System-unit (I believe), changing
it does not take much of the performance.
function Float2Str(f:Float):string
var
olddec: char;
begin
olddec := decimalseperator;
decimalseperator := '.';
Result := FloatToStr(f);
decimalseperator := olddec;
end;
bert
end;
--
REALbasic news and tips: http://rbgazette.com
KidzMail & KidzBlog: http://haranbanjo.com
