Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 23:30:59 +, David Starner via Unicode wrote:
> 
> On Tue, Jan 30, 2018 at 2:23 AM Alastair Houghton via Unicode  wrote:
>
> > This pattern exists across the board at the two companies; the Windows API 
> > hasn’t changed all that much
> > since Windows NT 4/95, whereas Apple has basically thrown away all the work 
> > it did up to Mac OS 9 and is
> > a lot more aggressive about deprecating and removing functionality even in 
> > Mac OS X/macOS than Microsoft
> > ever was.
>
> I'm not really clear on all the Windows details, as a long time Linux 
> programmer, but Mac OS X (2001) was
> 16 years ago and Windows 95 (1995) is 22, so not much difference even taking 
> your numbers. The .NET framework
> debuted in 2002, and the Universal Windows Platform debuted with Windows 8 in 
> 2012, so Microsoft has made some
> pretty large changes since NT 4. They do seem to more focused on keeping 
> backwards compatibility layers, but it's
> not that they've been not "prepared to make radical changes". 

I donʼt think that Alastairʼs point was about Microsoft not being innovative.
They simply allow old software to be used on new machines and Windows 
versions, something that Apple reportedly does not on macOS.

However, as of Unicode support by keyboard layouts, the current advice
is that adding new functionalities to Windows 10 would keep them out of 
reach for users of older versions of Windows, and new keyboard layouts 
relying on them would be truncated for a still huge part of the users. That is 
surely part of the “significant, perhaps insurmountable headwinds” faced by 
“making significant changes to user32.dll”, Andrew Glass warned in 2015:

http://www.unicode.org/mail-arch/unicode-ml/y2015-m08/0042.html

Perhaps there could be a way to update older frameworks via Windows Update, 
making an end with “limitation[s] of the Windows USER keyboard architecture” 
that Michael Kaplan pointed in response to Karl Pentzlin, January 2010:

http://www.unicode.org/mail-arch/unicode-ml/y2010-m01/0030.html

Several discussions, in the past years, stated that we should be able to input 
combining sequences using dead keys, a feature supported by macOS and Linux 
natively, while Windows does not come along with that kind of support, although 
this is recommended by TUS: “It is straightforward to adapt such a system to 
emit 
combining character sequences or precomposed characters as needed.” (5.12, p. 
222)

http://www.unicode.org/versions/Unicode10.0.0/ch05.pdf#G1076

In a 2015 discussion we/I also learned that Tavultesoft Keyman, now SIL, 
provides 
all these features and is cross-platform, and had a free offer since long, now 
even 
including the Developer tooling thanks to backing by SIL. Iʼm advertising this 
software 
to advocate Microsoftʼs presumed position: For all that goes beyond legacy 
support, 
we can rely on Keyman. 

As a consequence, layouts that are to be shipped with Windows, such as the new 
French, must stick with Windows resources (input editors are excluded by spec), 
whereas minority languages needing extended functionalities can promote 
additional 
software for support, as far as they are not expected to be supported 
out-of-the-box.

Hopefully we can now expect, by contrast, that Apple will add the missing 
toggle, 
internally VK_KANA on Windows (Linux is reported to have it, too), to make it 
available on macOS as well.

Regards,

Marcel

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[David Starner via Unicode]

On Tue, Jan 30, 2018 at 2:23 AM Alastair Houghton via Unicode <
unicode@unicode.org> wrote:

> This pattern exists across the board at the two companies; the Windows API
> hasn’t changed all that much since Windows NT 4/95, whereas Apple has
> basically thrown away all the work it did up to Mac OS 9 and is a lot more
> aggressive about deprecating and removing functionality even in Mac OS
> X/macOS than Microsoft ever was.
>

I'm not really clear on all the Windows details, as a long time Linux
programmer, but Mac OS X (2001) was 16 years ago and Windows 95 (1995) is
22, so not much difference even taking your numbers. The .NET framework
debuted in 2002, and the Universal Windows Platform debuted with Windows 8
in 2012, so Microsoft has made some pretty large changes since NT 4. They
do seem to more focused on keeping backwards compatibility layers, but it's
not that they've been not "prepared to make radical changes".

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 08:18:49 +0100, Philippe Verdy wrote:
> 
> I have always wondered why Microsoft did not push itself at least the five
> simple additions needed since long in French for the French AZERTY LAYOUT:

Many people in Fɽanƈë are wondering, but it is primarily a matter of honoring 
a countryʼs policies and not interfering with official work. France is expected 
to 
fix itself its keyboarding problems and publish a standard, and thatʼs what is 
actually happening. See Shawn Steeleʼs blog post about Locale Data in Windows 
10 & CLDR:

https://blogs.msdn.microsoft.com/shawnste/2015/08/29/locale-data-in-windows-10-cldr/

> - [AltGr]+[²] to produce the cedilla dead key (needed only before capital C 
> in French) :
> this is frequently needed, the alternative would be [AltGr]+[C] to map "Ç" 
> without the dead key;

That would be easier than Alt+0199. But Alt+something should yield consistently 
either uppercase 
or lowercase. Then, especially in the United States, not having all uppercase 
letters accessed with 
Shift+lowercase is considered counter-intuitive. And when the lowercase letter 
is directly accessed, 
going through a dead key to get its uppercase is not something I would 
recommend. Therefore, 
all uppercase that are used as initials (not Ù) should be Shift+lowercase, and 
digits in AltGr like on 
a few Latin layouts shipping with Windows, plus a Programmer toggle described 
in:

https://unicode.org/cldr/trac/ticket/10851#comment:2

> spell checkers forget the frequent words: Ça or Ç'.

I never use spell checkers, and when they show up with red wavy underline, I 
quickly try to disable 
them (outside of Gooogle Search). That is why I have typos. [This one has 
occurred unintentionally.]

>
> - [AltGr]+[1&] to produce the acute accent dead key (similar to [AltGr+7è`] 
> giving the grave accent deadkey) :
> this is the most frequent missing letter we need all the time.

Therefore, the É should be mapped to a live key. But the acute dead key is 
really the missing one. 
Belgiumʼs AZERTY has it. Getting É at least by dead key would have divided our 
trouble by half.

>
> - [AltGr]+[O] to produce "œ" (without ShiftLock or CapsLock mode enabled),
> or "Œ" (in ShiftLock or CapsLock mode), and
> [AltGr]+[Shift]+[O] to produce "Œ" (independantly of [ShiftLock] which is 
>disabled by [Shift], but without [CapsLock])
> or "œ" (independantly of [CapsLock], but without [ShiftLock]) :
> this is needed occasionnaly for very few common words, the most frequent 
> omission is "Œuf" or its plural "Œufs".

To repay the Œœ for its exclusion from Latin-1 (due to a Frenchman), it should 
be granted 
two key positions in the Base and Shift shift states, amidst the upper row 
letters.

>
> - [AltGr]+[A] to produce "æ" (without ShiftLock or CapsLock mode enabled),
> or "Æ" (in ShiftLock or CapsLock mode), and
> [AltGr]+[Shift]+[O] to produce "Æ" (independantly of [ShiftLock] which is 
>disabled by [Shift], but without [CapsLock])
> or "æ" (independantly of [CapsLock], but without [ShiftLock]) :
> this is rarely needed, except for a few words borrowed from Latin used in 
> biology or some legal/judiciary terminology.

And one spelling of _Lætitia_.

>
> - Adding Y to the list of allowed letters after the dieresis deadkey to 
> produce "Ÿ" :
> the most frequent case is L'HAŸE-LÈS-ROSES, the official name of a French 
> municipality when written with full capitalisation,
> almost all spell checkers often forget to correct capitalized names such as 
> this one.

Thatʼs really something I never understood neither. Why that deadlist was not 
updated. 
Maybe like above: If Microsoft had updated our layout with 'Ÿ', we could have 
wondered 
why they didnʼt add the other missing stuff while they were on it.

>
> This would allow typing French completely including on initial capitals.
> All other French capital letters can be typed (ÂÊÎÔÛ with the circumflex dead 
> key,
> ËÏÜŸ with the dieresis dead key which already allows ÄÖ not needed for French 
> but for Alsatian or some names borrowed from German).
>
> But we have mappings already in the AZERTY layout for:
> - the tilde as a dead key on [AltGr]+[2é~], even if it is not used for French 
>but only for "ñ" or "Ñ" in names from Spanish or Breton,

That didnʼt prevent Breton authorities from refusing it in a first name, 
Denis Jacquerye reported in the wake of the Kazakh apostrophe thread:

http://unicode.org/mail-arch/unicode-ml/y2018-m01/0133.html

> " ÃÕ" not needed at all, /ãõ/ needed only for standard French IPA phonetics 
> where we still can't type /ɑɡʀɔɲ/ for French phonetics
> - the grave accent as a dead key on [AltGr]+[7è`], needed for "ÀÈ" but 
>allowing also "ÌÒÙ" not used at all in French.
>
> There's not any good rationale in the French AZERTY layout to keep it 
> incomplete on capitals
> while maintaining other capital letters with diacritics composed with dead 
> keys but not needed at all in French,
> except the case of "ŸœŒ" missing from ISO 8859-1 

RE: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 11:50:49 -0700, Doug Ewell wrote:
> 
> Marcel Schneider wrote: 
> >
> > http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html
> >  
> >
> > Sadly the downloads are still unavailable (as formerly discussed). But 
> > I saved in time, too (June 2015). 
>
> Sorry, try this: 
>
> http://vrici.lojban.org/~cowan/MobyLatinKeyboard.zip

Thank you!

Iʼve gone through John Cowanʼs Home Page, too:

http://vrici.lojban.org/~cowan/

Regards,

Marcel

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 11:34:40 -0700, Doug Ewell via Unicode wrote:
> 
> Marcel Schneider wrote:
> 
> > That tends to prove that Mac users accept changes, while Windows users
> > refuse changes.
> 
> I was going to say that was a gross over-generalization, but that didn't
> adequately express how gross it was. It's just plain wrong. Pardon my
> bluntness.
> 
> How about: Windows is often used in the workplace, where users may not
> have the freedom or motivation to make their own changes and be
> different from other users, while Macs are often used by individuals who
> do. That's an over-generalization too, but not quite at the level of
> "Windows users refuse changes."

Iʼm relieved to be wrong, and that “such a discrepancy” that “I fail[ed] to 
understand” doesnʼt exist.

I know a company that prescribes and delivers Apple hardware to all its 
affiliates. Second-hand retailers offer very few Apple machines while they 
have plenty of PC computers, whose turnover at business customers is
two years. Apple computers are not replaced every two years in workplaces. 
That may be a reason why Apple Inc. takes steps to get them replaced 
nevertheless, as Alastairʼs report you quoted [and I already answered] 
might suggest (but stop, no more over-interpretation!).

>
> Alastair Houghton replied:
> 
> > I think, rather, that Apple is (or has been) prepared to make radical
> > changes, even at the expense of backwards compatibility and even where
> > it knows there will be short term pain from users complaining about
> > them, where Microsoft is more conservative.
> 
> That too. Good point. 

Very good point.

Regards,

Marcel

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 10:20:46 +, Alastair Houghton wrote:
> 
> On 30 Jan 2018, at 05:31, Marcel Schneider via Unicode  wrote:
> > 
> > OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
> >> 
[…]
> >> 
> >> They are also all on the MacOS "US International PC", provided since 2009 
> >> by Apple
> >> for Windows users who like US International.
> > 
> > I suppose that this layout ships with the Windows emulation that can be run 
> > on a Mac.
> 
> No. It’s included as standard with the macOS itself. Go to System 
> Preferences, choose “Keyboard”, then “Input Sources”.
> Click the “+” button at the bottom left, then enter “PC” in the search field 
> and you’ll see there are a range of “PC” layouts.

Indeed. Itʼs sort of a mix made of Appleʼs common US and Windowsʼ 
US-International. 
So it has the five Windows-style dead keys in Base and Shift, AND the five 
Mac-style 
dead keys (for the same diacritics) in Option.

> 
> >> œ Œ are on alt and alt-shift q
> >> 
> >> ‹› are on alt-shift 3/4
> 
> More of a nitpick than anything, but Apple keyboards have *Option*, not 
> “alt”. Yes, some (but not all) keyboards’ Option keys have an “alt” 
> annotation at the top, but that was added AFAIK for the benefit of people 
> running PC emulation (or these days, Windows under e.g. VMWare 
> Fusion). The “alt” annotation isn’t on the latest keyboards (go look in an 
> Apple Store if you don’t believe me :-)).

Then, “alt” is obsoleted on Mac, and calling them “Option” is correct? Iʼm 
relieved if so, as I 
used “Option” when referring to macOS, or better, “AltGr/Option” to be 
cross-platform…
“Option” is shorter, but “AltGr” is already printed on most keyboards, though 
it isnʼt a short 
form of an easily localizable term, while “Option” is multi-locale (English, 
French, German, …).

> 
> > Then this is ported from the Apple US layout, where these characters are in 
> > the same 
> > places. However that does not include correct spacing, as required for 
> > French.
> 
> Not sure what you mean about spacing. That, surely, is a matter mainly for 
> the software you’re using, rather than for a keyboard layout?

It may be handled by an input editing functionality as embedded in Word, like 
many things 
can be done by input editing, even “œ” (for which Word has also a shortcut: 
Ctrl+&, o) 
because Microsoft and Bill Gates in person were eager to support the French 
locale and 
did a lot to help French efforts in keyboarding. But properly, correct spacing 
must be 
handled on keyboard level, otherwise weʼll always end up with a mass of wrong 
data 
amidst which a subset of correct documents having U+202F NARROW NO-BREAK SPACE 
before ‘?’ and ‘!’ and ‘;’, and even ‘»’ and after ‘«’, and currently also 
before ‘:’ as 
Philippe Verdy wrote to this List on Fri, 26 Jun 2015 22:16:48 +0200:

http://www.unicode.org/mail-arch/unicode-ml/y2015-m06/0220.html

“Les éditeurs de presse et de livres en France utilisent tous des fines de
chasse fixe dans leurs moteurs de composition”
(“Print media and book publishers in France all use fixed-width narrows in 
their typesetting engines”)

Unicode did not support interoperable French typesetting until it encoded 
U+202F for Mongolian, in 1999, six years after v1.1 of the Standard. 
Making U+2008 PUNCTUATION SPACE a no-break space would have been
well done. This was seemingly encoded for hot-metal typesetting of tables, 
like U+2012 FIGURE DASH and U+2007 FIGURE SPACE that is non-breakable.
While U+2007 can be considered a fixed-width counterpart of U+00A0, and
U+2012 could have been a longer variant of U+2212 to denote intervals 
*if only* it had been specified as such, U+2008 could have been the proper 
representation of French punctuation spacing, instead of ending up as a 
completely useless character, depriving the French locale of Unicode support.
See the feedback items about these topics that have been posted so far:

http://www.unicode.org/L2/L2018/18009-pubrev.html#Error_Reports

> 
> >> (US Extended has also been renamed ABC Extended back in 2015)
> > 
> > Presumably because it is interesting for many locales worldwide accustomed 
> > to the 
> > US QWERTY layout. That tends to prove that Mac users accept changes, while 
> > Windows users refuse changes. However I fail to understand such a 
> > discrepancy.
> 
> I don’t think it’s the users.
> 
> I think, rather, that Apple is (or has been) prepared to make radical 
> changes, even at the expense of backwards compatibility and even where it 
> knows there will be short term pain from users complaining about them, where 
> Microsoft is more conservative. This pattern exists across the 
> board at the two companies; the Windows API hasn’t changed all that much 
> since Windows NT 4/95, whereas Apple has basically thrown away 
> all the work it did up to Mac OS 9 and is a lot more aggressive about 
> deprecating and removing functionality even in Mac OS X/macOS than 
> Microsoft ever was.
> 
> This is exemplified, actually, by the 

RE: Keyboard layouts and CLDR

[Doug Ewell via Unicode]

Marcel Schneider wrote:

>> http://recycledknowledge.blogspot.com/2013/09/us-moby-latin-keyboard-for-windows.html
>
> Sadly the downloads are still unavailable (as formerly discussed). But
> I saved in time, too (June 2015).

Sorry, try this:

http://vrici.lojban.org/~cowan/MobyLatinKeyboard.zip
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Keyboard layouts and CLDR

[Doug Ewell via Unicode]

Marcel Schneider wrote:

> That tends to prove that Mac users accept changes, while Windows users
> refuse changes.

I was going to say that was a gross over-generalization, but that didn't
adequately express how gross it was. It's just plain wrong. Pardon my
bluntness.

How about: Windows is often used in the workplace, where users may not
have the freedom or motivation to make their own changes and be
different from other users, while Macs are often used by individuals who
do. That's an over-generalization too, but not quite at the level of
"Windows users refuse changes."

Alastair Houghton replied:

> I think, rather, that Apple is (or has been) prepared to make radical
> changes, even at the expense of backwards compatibility and even where
> it knows there will be short term pain from users complaining about
> them, where Microsoft is more conservative.

That too. Good point.

--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: Keyboard layouts and CLDR

[Marcel Schneider via Unicode]

On Tue, 30 Jan 2018 08:54:19 -0700, Tom Gewecke wrote:
> 
> > On Jan 30, 2018, at 3:20 AM, Alastair Houghton  wrote:
> > 
> > The “alt” annotation isn’t on the latest keyboards (go look in an Apple 
> > Store if you don’t believe me :-)).
> 
> Interesting! Apple’s documentation shows these keys mostly with “alt” and “⌥”.
> 
> https://support.apple.com/en-us/HT201794

While the “⌥” symbol is persistent across locales, the “alt” label is somewhere 
replaced with “option” and I believed that this the macOS name, whereas “alt” 
is merely wrt BootCamp users. However that is confusing as Windows “Alt” has 
not the “option” functionality but rather the quick access like its internal 
name of 
“MENU” (‷LMENU‴, ‷RMENU‴), while “option” equals “AltGr” since there are 
alternate graphics, too. But now since we need a “Numbers” modifier, none of 
both schemes seems appropriate: Left Option should be Numbers, and Alt should 
become Numbers, too, while itself could be mapped to Left Windows or so. See:

https://unicode.org/cldr/trac/ticket/10851#comment:2

Regards,

Marcel

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Tom Gewecke via Unicode]

> On Jan 30, 2018, at 3:20 AM, Alastair Houghton  
> wrote:
> 
>   The “alt” annotation isn’t on the latest keyboards (go look in an Apple 
> Store if you don’t believe me :-)).

Interesting!  Apple’s documentation shows these keys mostly with “alt” and “⌥”.

https://support.apple.com/en-us/HT201794

Re: Keyboard layouts and CLDR

[Eric Muller via Unicode]

Indeed.

But "Faÿ-lès-Nemours" / "FAŸ-LÈS-NEMOURS". "lès" in French place names 
means "near", typically followed by another city name or a river name.


In the case of "L'Haÿ-les-Roses", it's just that they have a famous rose 
garden, so "les".


Eric.

On 1/30/2018 12:06 AM, Martin J. Dürst via Unicode wrote:

On 2018/01/30 16:18, Philippe Verdy via Unicode wrote:

  - Adding Y to the list of allowed letters after the dieresis 
deadkey to
produce "Ÿ" : the most frequent case is L'HAŸE-LÈS-ROSES, the 
official name
of a French municipality when written with full capitalisation, 
almost all
spell checkers often forget to correct capitalized names such as this 
one.


Wikipedia has this as L'Haÿ-les-Roses (see 
https://fr.wikipedia.org/wiki/L'Haÿ-les-Roses). It surely would be 
L'HAŸ-LES-ROSES, and not L'HAŸE-LÈS-ROSES, when capitalized. I of 
course know of the phenomenon that in French, sometimes the accents on 
upper-case letters are left out, but I haven't heard of a reverse 
phenomenon yet.


Regards,   Martin.

Re: Keyboard layouts and CLDR (was: Re: 0027, 02BC, 2019, or a new character?)

[Alastair Houghton via Unicode]

On 30 Jan 2018, at 05:31, Marcel Schneider via Unicode  
wrote:
> 
> OnMon, 29 Jan 2018 11:13:21 -0700, Tom Gewecke wrote:
>> 
>>> On Jan 29, 2018, at 4:26 AM, Marcel Schneider via Unicode  wrote:
>>> 
>>> 
>>> the Windows US-Intl 
>>> does not allow to write French in a usable manner, as the Œœ is still 
>>> missing, and does not allow to type German correctly neither due to 
>>> the lack of single angle quotation marks (used in some French locales, 
>>> too, and perhaps likely to become even more widespread). Of course 
>>> these are all on the macOS US-Extended.
>> 
>> They are also all on the MacOS "US International PC", provided since 2009 by 
>> Apple
>> for Windows users who like US International.
> 
> I suppose that this layout ships with the Windows emulation that can be run 
> on a Mac.

No.  It’s included as standard with the macOS itself.  Go to System 
Preferences, choose “Keyboard”, then “Input Sources”.  Click the “+” button at 
the bottom left, then enter “PC” in the search field and you’ll see there are a 
range of “PC” layouts.

>> œ Œ are on alt and alt-shift q
>> 
>> ‹› are on alt-shift 3/4

More of a nitpick than anything, but Apple keyboards have *Option*, not “alt”.  
Yes, some (but not all) keyboards’ Option keys have an “alt” annotation at the 
top, but that was added AFAIK for the benefit of people running PC emulation 
(or these days, Windows under e.g. VMWare Fusion).  The “alt” annotation isn’t 
on the latest keyboards (go look in an Apple Store if you don’t believe me :-)).

> Then this is ported from the Apple US layout, where these characters are in 
> the same 
> places. However that does not include correct spacing, as required for French.

Not sure what you mean about spacing.  That, surely, is a matter mainly for the 
software you’re using, rather than for a keyboard layout?

>> (US Extended has also been renamed ABC Extended back in 2015)
> 
> Presumably because it is interesting for many locales worldwide accustomed to 
> the 
> US QWERTY layout. That tends to prove that Mac users accept changes, while 
> Windows users refuse changes. However I fail to understand such a discrepancy.

I don’t think it’s the users.

I think, rather, that Apple is (or has been) prepared to make radical changes, 
even at the expense of backwards compatibility and even where it knows there 
will be short term pain from users complaining about them, where Microsoft is 
more conservative.  This pattern exists across the board at the two companies; 
the Windows API hasn’t changed all that much since Windows NT 4/95, whereas 
Apple has basically thrown away all the work it did up to Mac OS 9 and is a lot 
more aggressive about deprecating and removing functionality even in Mac OS 
X/macOS than Microsoft ever was.

This is exemplified, actually, by the length of time Microsoft keeps backwards 
compatibility layers, versus the length of time Apple does so.  The WoW 
subsystem is (I think) still part of the 32-bit builds of Windows, so they can 
still run Windows 3.1 software, DOS software and so on (i.e. software back to 
the 1980s).  Apple, on the other hand, dropped support for “Classic” Mac apps 
back in 10.4 and has never supported running PowerPC classic apps on any Intel 
machine.  Indeed, six years ago now, in Mac OS X 10.7, Apple dropped support 
for running PowerPC apps built for Mac OS X, which basically means that 
software Mac users bought to run on their older PowerPC-based Macs is now not 
usable on new machines.

Kind regards,

Alastair.

--
http://alastairs-place.net

Re: Keyboard layouts and CLDR

[Martin J. Dürst via Unicode]

On 2018/01/30 16:18, Philippe Verdy via Unicode wrote:


  - Adding Y to the list of allowed letters after the dieresis deadkey to
produce "Ÿ" : the most frequent case is L'HAŸE-LÈS-ROSES, the official name
of a French municipality when written with full capitalisation, almost all
spell checkers often forget to correct capitalized names such as this one.


Wikipedia has this as L'Haÿ-les-Roses (see 
https://fr.wikipedia.org/wiki/L'Haÿ-les-Roses). It surely would be 
L'HAŸ-LES-ROSES, and not L'HAŸE-LÈS-ROSES, when capitalized. I of course 
know of the phenomenon that in French, sometimes the accents on 
upper-case letters are left out, but I haven't heard of a reverse 
phenomenon yet.


Regards,   Martin.