CVS difference for ai05s/ai05-0127-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0127-1.txt

--- ai05s/ai05-0127-1.txt	2009/11/03 01:19:04	1.3
+++ ai05s/ai05-0127-1.txt	2010/01/09 01:31:29	1.4
@@ -1116,3 +1116,68 @@
 effort to implement something so useless :-)
 
 ****************************************************************
+
+From: Pascal Leroy
+Date: Sunday, November 15, 2009  8:01 AM
+
+> A.19 The Package Locales
+>
+> The package Locales provides operations for querying and determining the locales
+> associated with the environment.
+>
+> Static Semantics
+>
+> The library package Locales has the following declaration:
+>
+> package Ada.Locales is
+>
+>   type Language_Code is array (1 .. 2) of Character range 'a' .. 'z';
+>   type Country_Code is array (1 .. 2) of Character range 'A' .. 'Z';
+>
+>  Max_Variant_Length : constant Natural;
+
+I couldn't find a normative reference in this AI, but it seems to be based on an
+ancient standard.  FWIW, language codes can now have 3 characters (there are
+more than 1000 of them), and you cannot in general define a locale without
+specifying the script, as some languages (eg Uzbek) have changed script over
+time, and the script impacts the collation rules.
+
+This AI only scratches the surface of l10n/i18n issues, and if it made it into
+the language as currently written I believe that it would be actively harmful,
+as it doesn't even come close to addressing the complexity of the problem.  For
+instance the Calendar package is specialized for the Gregorian calendar, which
+is inappropriate for many/most locales.  For details about the state of the
+practice in this area, look for BCP 47 on Wikipedia.
+
+As others have pointed out, integrating i18n into the language would be a
+gigantic effort, and I'm not sure that the ARG has the necessary know-how in
+this area, so I would suggest to drop the AI entirely.
+
+****************************************************************
+
+From: Bob Duff
+Date: Sunday, November 15, 2009  5:01 PM
+
+> As others have pointed out, integrating i18n into the language would
+> be a gigantic effort, and I'm not sure that the ARG has the necessary
+> know-how in this area, so I would suggest to drop the AI entirely.
+
+I agree.
+
+I certainly have little know-how in this area.  From reading-up on this area, it
+seems like i18n should be left as an OS issue, not a language issue.
+
+If we try to do something, we will do it badly, and that's worse than doing
+nothing.
+
+P.S. Hi, Pascal, good to hear from you!
+
+****************************************************************
+
+From: Robert Dewar
+Date: Sunday, November 15, 2009  5:54 PM
+
+I strongly agree with Pascal, we have no noticeable user interest in this, and
+doing a half-baked job would be a step backward. Drop this AI entirely.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent