Alex,
add Parameter  

Parameter XMLTYPE = "A_CHILD";

to one of your child classes
inherited comment is somewhat vague:

/// This parameter provides the default XMLTYPE for the class. If it is
/// empty then the class name will be used to construct a default XML type.
/// 
/// The default XMLTYPE is used when naming and referencing this type
/// in a schema and the schema context did not provide an XML type name.

documentation  is more precise:

For an XML-enabled class or a property that is based on an XML-enabled class, the XML type is determined as follows:
If the class has a value for the XMLTYPE parameter, that is used as the type name.
Otherwise, the
short class name is taken as the XML type name.

so you would have 2 different classes with the same type:  CHILD
that's not allowed in an XML schema they have to be unique.

OK, There wasn't much echo so far.

The workaround was to encode the Description (and limit it for indexing) according to the language used.
The encoding is basically the position in the list of allowed/used characters or character groups.
If we use also numbers and interpunctuation it has to go into our list.

Instead of %String the descriptions are stored in a serial class:

Class DC.ArticleSort Extends (%SerialObject)
{
Property Language As %String [ InitialExpression = ];
Property Description As %String(MAXLEN = "");
Property Sort As %String(COLLATION = "EXACT", MAXLEN = 300) [  SqlComputed,
       ,
SqlComputeCode = { Set {*} = ##class(DC.ArticleSort).Encode({Language},{Description}) }
      ,
SqlComputeOnChange = (Description, Language) ];

ClassMethod Encode( Lang As %String, Desc As %String(MAXLEN="")) As %String(MAXLEN=300)
{ ...replace valid characters by binary postion value ..  }
}

It's obvious that for English and your installed NLS no encoding is required.
For triplets or doublets like in Hungarian, you need several runs  to encode

The Query itself has a minor change

SELECT TOP 10 ArtNr,DescHU_Description FROM DC.Article
      WHERE DescHU_Description %STARTSWITH 'BE'
      ORDER BY DescHU_Sort

The encoding is definitely not fast but change frequency is not an issue here and change happens
by typing in descriptions on the keyboard.

Query performance is supported by this index construct:

     Index IdxHU On DescHU.Sort [ Data = (ArtNr, DescHU.Description) ]; 

So the query plan just iterates over this index.
 

Marco you are RIGHT !

The example is just wrong! And never got fixed.

Instead of   set status = adapter.%Open("R")

it should be set status = adapter.Open("R")

This are 2 differnet methods with total different incompatible parameters. 

it is good practice to close the file after use by  do adapter.Close() 

I personally deeply distrust all products from Microsoft and their management tools

BUT:

If your Caché is installed on a 64bit Windows you also need to use 64bit ODBC drivers.
Removing the 32bit DSN for Caché might solve your issue.
As your screenshot says (in German) you can do this only with a 32bit ODBC administrator tool. 
 

#1) thanks for the Reminder on  IRIS

#1) + #2) concentrate on finding. but that's not the key issues.

As an example: The problem becomes visible when you run   

SELECT TOP 10 ArtNr,DescDE FROM Dc.Article WHERE DescDE %Startswith 'BE' ORDER by DescDE 


The problem is to get control of ORDER which depends on global collation.

Example for German:
- With Standard collation, you sort A,B,C..,O,...,U,...Z,Ä,Ö,Ü...   (classic ANSI sort)
- With collation German3, you sort A,Ä,B,C,....O,Ö,....U,Ü,....Z 

It is mostly the handling of characters with diacritical signs.

Hungarian is my worst case with much more diacriticals AND groups of characters in total  44 "character" tokens

A Á B C Cs D Dz Dzs E É F G Gy H I Í J K L Ly M N Ny O Ó Ö Ő P Q R S Sz T Ty U Ú Ü Ű V W X Y Z Zs

If you do it correctly then Cx sorts before Cs and Gz should sort before Gy and so on.

Now for ORDER BY you typically get your default collation derived from NLS settings.

#3) custom index seems to offer the most promising features.