Please drop UTF-8@euro locales

Reassigning to glibc. This change is probably for Hoary ?

What will happen to users who are using the @euro locales if they are removed?
Does glibc fall back sanely?

No, they have to install a xx_XX.UTF-8 locale and use it.
Anyway as far as I am concerned, you can close this bugreport if you want, my point was to have these meaningless locales being removed before they reach stable releases so that this question does not get asked ;)

Unfortunately, the issue was raised too close to the final release to make a
change like this. Even if it had been raised earlier, we would have needed to
address the upgrade issues, because we support upgrades from Woody.

If these locales should be removed, it makes sense to remove them in hoary, and
provide some upgrade path.

Woody does not support these locales, they have been introduced
in Debian glibc 2.3.1-12.

If you still wonder whether they should be removed, a good start
is to investigate why they have been added at the first place.
My conclusion so far is that they were introduced in Red Hat 8
(a.k.a let-switch-to-utf8-and-see-what-is-broken, 2002/09), then
picked up by Debian maintainers (2003/02). UTF-8 locales are
officially supported by glibc upstream since 2004/01, and someone
cleaned up Red Hat patches as these useless UTF-8@euro locales
have been dropped in Fedora 2 (2004/05). So IMO they have been
added to RH8 by people who did not fully understand what they
were doing, and everybody (including myself) blindly followed up
without noticing that they are useless.

The concept of locales in Unix is not trivial, and providing
unneeded alternatives only lead to confusion. In order to educate
users, I am in favour of dropping those confusing UTF-8@euro
locales and let users migrate to UTF-8; there are no technical
problems to provide an upgrade path in the locales package, no
idea for other components.

*** Bug 13042 has been marked as a duplicate of this bug. ***

I'm marking this bug as 'later'. We'll have to write proper transition scripts
anyway, since we released Warty with this. It's probably better to do this when
we do the major surgery to glibc to bring it up to a more recent version.

Reopenning bug, setting target milestone to 5.10

Too late for 5.10; this should have been done much earlier.

What is the status of this bug, given the proposal to use the belocs locales?
https://launchpad.net/distros/ubuntu/dapper/+specs
https://wiki.ubuntu.com/LocalesThatDontSuck

This bug had been fixed in 5.10, I cannot see any
UTF-8@euro locales in /usr/share/i18n/SUPPORTED,
thanks.

Being the bug submitter, I believe that I am
entitled to close it myself, sorry if I am wrong.

I still had fr_FR.UTF-8@euro configured after my latest upgrade to Feisty.

Using UTF-8@euro LOCALE triggered a bug in Quanta+ making it unable to input special and accentuated characters within the editor.

Had to mention this as a consequences of this bug in a user perspective. Other wierdness bugs may trigger when using this type of LOCALE and the upgrading process could/should? cleanup this.