To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=50670
------- Additional comments from [EMAIL PROTECTED] Wed Jul 6 06:50:09 -0700
2005 -------
I will suggest that the correct solution to this problem is to follow the source
locale. For a discussion of which locale to use I offer the following:
I see two locales that could be obeyed:
1. The locale of the ooo application being used
2. the locale or language of the data being imported.
I will argue that it should be the latter that is used.
Consider that there is a string "1,000" in the document to import, eg a
HTML document. The meaning could be 1000 or 1 dependent of the locale that this
document was generated with. But the meaning surely should not change
due to the locale that is used in the importing application, eg calc.
An American and a Dane should get the same number into the calc
application, from the same imported document. The numbers of the
imported tables should stay the same.
In HTML/XML there is an entity that defines the language of the data,
namely the "lang" variable. This defines the value of the decimal and
thousands separator, which are language defined. Eg for Danish it is
defined in the Danish orthography specification "Retskrivningsordbogen" that
comma is used as the decimal separator. Likewise for English it is always the
period that is used.
If no language is specified for the data, then the default should be
used, which for HTML and XML is period for the decimal separator and
comma for the thousands separator. One should not use the locale
information of the importing application, but always use the language
spec for the data.
One could then introduce in the application a setting to override
the data locale, to be used when the data is marked up wrongly.
This should not be a prompt, as that would be unnecessary cumbersome in
most cases - to be asked this question every time one imports data.
I would welcome a solution that implements this as dependent on a
environment variable, although I believe to follow the language
indication of the data is the obviously correct solution. This is also in
accordance with current internationalization theory in the object oriented
world.
Should a solution as the one Eike proposes be implemented, I suggest that one of
the options would be that the source locale be used, eg. by using a string
"x-source-locale" to indicate to use the "lang" markup or other language or
locale specification of the source data. The behaviour on what to do if the lang
do not describe an actual locale could well be the one Eike describes.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
