--- Begin Message ---
Hi!
At the first moment your proposal sounds reasonable. But if you extend DESC
into different languages, do you expect that all objectType standards will be
revised to add translations to every desired language? If not, how will there
be an agreement of "standard" translations?
I think that DESC was not intended for the end-user.
For a solution, I'm afraid you'll have to provide your own "local"
translations. Actually I did something like that in Perl for a CGI application
some years ago:
# map LDAP attributes to style names and to translations
use constant LDAP_ATTRS => {
'c' => {
'aliases' => ['countryName'],
'DE' => 'LÃndercode',
'style' => ''
},
'cn' => {
'aliases' => ['commonName'],
'DE' => 'Name',
'style' => 'ds-nam'
},
'description' => {
'DE' => 'Beschreibung',
'style' => ''
},
[...]
For more applications one could store that in LDAP also; maybe invent a schema
describing translations for attribute names.
Note: I'm translating the attribute _names_, not the descriptions, but you
could also do that for each objectType...
I guess it's easier to agree on a translation schema that on actual
translations ;-)
Regards,
Ulrich
>>> Zhang Weiwu <zhangweiwu@realss.com> schrieb am 05.08.2013 um 17:52 in
Nachricht
<alpine.DEB.2.00.1308052316340.15060@lyonesse>:
> GUI explains to the end user what each field is about, by reciting DESC of
> olcAttributeTypes - this design seems passable, after all, DESC is intended
> to describe the attribute type. This method worked for years.
>
> Now user base grows, there are speakers of different languages. It is
> required the field being described in multiple languages.
>
> Had DESC been like the 'description' attribute type, an attribute type
> defined in RFC2256, then I would be able to use language modifier:
>
> description: Weight, in kg. It is used to screen health problems.
> description;lang-zh: äéïçäææååééã
>
> But it is not.
>
> I can see only two ways to workaround the problem:
>
> 1. Extend DESC. This look ugly but simple:
>
> ... NAME 'ibmWeight' DESC 'Your weight, in kg. It is used to screen health
> problems.|lang-zh: æçäéïçäææååééã' ...
>
> The application would read DESC, split it by vertical-bars, find the
> langauge that matches the users's and only display that part.
>
> 2. Build a shadow entry for every attributeType:
>
> dn: olcAttributeTypes=ibmWeight,cn=shadowAttributeTypes,dc=ibm,dc=com
> objectClass: ibmShadowAttributeType
> olcAttributeTypes: ibmWeight
> description: Weight, in kg. It is used to screen health problems.
> description;lang-zh: äéïçäææååééã
>
> and laboriously manually update shadow attribute entry when user add or
> modify existing olcAttributeTypes.
>
> What do you think? How can such a need can be solved?
>
> Thanks in advance!
>
> P.S. === about openldap's choice of design ===
>
> When a few years ago I learned that
> a attribute type is defined by adding an olcAttributeTypes attribute
> my first reaction was, why not design it in such a way, that
> a attribute type is defined by adding an olcAttributeType *entry*?
>
> Like this:
>
> --> objectClasss: olcAttributeType
> --> olcAttributeName: ibmWeight
> --> description: Weight, in kg. It is used to screen health problems.
> --> description;lang-zh: äéïçäææååééã
>
> The advantage, is to allow extension and inheritance. e.g. the following
> example has olcConstrainedAttributeType which inherits olcAttributeType
>
> --> objectClasss: olcAttributeType
> ++> objectClasss: olcConstrainedAttributeType
> --> olcAttributeName: ibmWeight
> --> description: Weight, in kg. It is used to screen health problems.
> --> description;lang-zh: äéïçäææååééã
> ++> olcConstraintRegex: [0-9.][0-9.]kg
>
> For usability reasons, some developer may as well add jpegPhoto into
> attribute type definition.
--- End Message ---