[www-issues] Re: [Issue 50670] HTML Import and Clipboard Paste behaviour
On Fri, Jul 08, 2005 at 11:50:14AM -, [EMAIL PROTECTED] wrote: 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] Fri Jul 8 04:50:12 -0700 2005 --- Folks, we can argue about this over and over again, but people commenting on this should at least read and _understand_ the discussion in the predecessor issue 39898 and not blow up this issue with the same things again, like 2. the locale or language of the data being imported. With HTML there is no locale associated with the data. Correct, but there may be a language. In HTML/XML there is an entity that defines the language of the data, namely the lang variable. Exactly, the _language_, but not the locale. Only for the cases where a language is clearly assigned to just and only one locale using this element would be possible. And most times the element isn't even present. So nothing we could rely on. This defines the value of the decimal and thousands separator, No, it doesn't. which are language defined. No, they aren't. They are defined per _locale_. Not in the real world. IRL as defined by orthogarphy standards, a thousands Eg for Danish it is defined in the Danish orthography specification Retskrivningsordbogen that comma is used as the decimal separator. Just because Danish is used almost only in Denmark and its regions. Likewise for English it is always the period that is used. By coincidence. For French, for example, it is a period in France (fr_FR), but a comma in Switzerland (fr_CH). Same for Spanish, different separators in many different countries. This is not my information. In Switzerland they use period as the thusands separator. I recently was in Genève and could evrify that. I also did create many locales, also for Latin Amarica, and that info was consistent also. Anyway, what I am asking for is just an option, users can choose not to use it. And you could actually specify in html more specific language codes, eg swizz french fr-ch. This is a valid RFC 3066 code. The default code to go from a language code to a locale, as you described, would be adequate, and generate acceptable results in many cases. Ok, back to something productive: I offered my solution in the comment of Wed Jun 29 05:39:15 -0700 2005. With that hack I will _not_ implement a different default that would break already existing documents with links to data that rely on the current behavior _unless_ User Experience / Program Management tell me to do so. If we can't agree we will have to postpone this for OOo2.0.1 or later to do a full-blown solution with UI and such. I am just asking you to provide one more option, the option to use the source language as defining the thousands and decimal delimiters. I can understand if you would not make this the default choice, but IMHO there are good theroretical and practical reasons for this to exist, and even to be the desired default. If we just make it an option, then we can try it out, and get some experience with it. Best regards keld - 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]
Re: [www-issues] Re: [Issue 50670] HTML Import and Clipboard Paste behaviour
On Jul 8, 2005, at 5:18 AM, Keld Jørn Simonsen wrote: On Fri, Jul 08, 2005 at 11:50:14AM -, [EMAIL PROTECTED] wrote: 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] Fri Jul 8 04:50:12 -0700 2005 --- Folks, we can argue about this over and over again, but people commenting on this should at least read and _understand_ the discussion in the predecessor issue 39898 and not blow up this issue with the same things again, like 2. the locale or language of the data being imported. With HTML there is no locale associated with the data. Correct, but there may be a language. In HTML/XML there is an entity that defines the language of the data, namely the lang variable. Exactly, the _language_, but not the locale. Only for the cases where a language is clearly assigned to just and only one locale using this element would be possible. And most times the element isn't even present. So nothing we could rely on. This defines the value of the decimal and thousands separator, No, it doesn't. which are language defined. No, they aren't. They are defined per _locale_. Not in the real world. IRL as defined by orthogarphy standards, a thousands Eg for Danish it is defined in the Danish orthography specification Retskrivningsordbogen that comma is used as the decimal separator. Just because Danish is used almost only in Denmark and its regions. Likewise for English it is always the period that is used. By coincidence. For French, for example, it is a period in France (fr_FR), but a comma in Switzerland (fr_CH). Same for Spanish, different separators in many different countries. This is not my information. In Switzerland they use period as the thusands separator. I recently was in Genève and could evrify that. I also did create many locales, also for Latin Amarica, and that info was consistent also. Anyway, what I am asking for is just an option, users can choose not to use it. And you could actually specify in html more specific language codes, eg swizz french fr-ch. This is a valid RFC 3066 code. The default code to go from a language code to a locale, as you described, would be adequate, and generate acceptable results in many cases. Ok, back to something productive: I offered my solution in the comment of Wed Jun 29 05:39:15 -0700 2005. With that hack I will _not_ implement a different default that would break already existing documents with links to data that rely on the current behavior _unless_ User Experience / Program Management tell me to do so. If we can't agree we will have to postpone this for OOo2.0.1 or later to do a full-blown solution with UI and such. I am just asking you to provide one more option, the option to use the source language as defining the thousands and decimal delimiters. I can understand if you would not make this the default choice, but IMHO there are good theroretical and practical reasons for this to exist, and even to be the desired default. If we just make it an option, then we can try it out, and get some experience with it. Best regards keld - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
