Re: [weirds] Internationalization Issues

[Kentaro Mori <[e-mail]>]

Byron-san;

(2012/10/24 14:12), Byron Ellacott wrote:
> Thank you both for your input.  If you are intending to implement a weirds service down the line, what would be your expectations on language support in the protocol?

'My current' expectations on language support are like follows:
(Frankly saying, I haven't completely caught up on the context/concept
of the protocol, so if they won't make sense for your arguments sorry
for that, and there is a possibility that I change my mind as my
understanding develops)

- default language (or character code) specification feature
In a case client has no ability to specify which language it prefers,
it would be not so good for server to return data of all language it
supports other than to return data by default language, as I believe
vast majority of whois.jprs.jp user won't expect to obtain data by 'both
of Japanese and English' or 'English only' (so you would be a very rare
user :)
; and I wonder this is a protocol stuff or not?

- language (or character code) tag for each element
There is a possibility some element has data by multiple languages (such
as Japanese and English) and the other element has data by a single
language (such as Japanese).  If language tag is for a set of elements,
client will have no clue for determining which element of one language
corresponds to which element of other language.

- character code specification feature
In Japan, sometimes client software encounters failure in automatic
judgment of encoding character code such as between ISO-2022-JP and
Shift-JIS, so apparent indication of encoding by server will be welcomed.

Thanks for questioning,

Kentaro

> 
>   Byron
> 
> On 24/10/2012, at 3:09 PM, MasaYUKI Okada <[e-mail]> wrote:
> 
>> Byron-san,
>>
>> I'm Masayuki Okada at JPNIC.
>>
>> Our WHOIS system(whois.nic.ad.jp:43) will response English(ASCII)
>> if '/e' is put into the character of the last of an input. 
>>
>> By default, it answers in Japanese(ISO-2022-JP). 
>>
>> About main registration records, JPNIC are collecting both Japanese 
>> and English as an mandantory.
>>
>> just for reference:
>>  - How to use JPNIC WHOIS - 
>>   http://www.nic.ad.jp/en/db/whois/
>>
>> --
>> Masayuki Okada
>> JPNIC
>>
>> (2012/10/24 11:59), Kentaro Mori wrote:
>>> Byron-san and folks,
>>>
>>> I'm Kentaro Mori from JPRS.
>>> (sorry for late reply)
>>>
>>> For Whois, JPRS collects English data as well as native (Japanese) one
>>> at the time registrant applies to .JP domain name registration.
>>> Additionally, the English data doesn't cover all of Japanese data,
>>> e.g., it is partial.
>>> ISO-2022-JP as character-set was a normal choice when JPRS (more
>>> correctly, JPNIC at that time) started Whois service, though we may have
>>> alternative choice such as UTF-8 now.
>>>
>>> --Kentaro
>>>
>>> (2012/10/22 9:56), Byron Ellacott wrote:
>>>>
>>>> On 19/10/2012, at 9:33 PM, Andy Newton <[e-mail]> wrote:
>>>>
>>>>> On 10/18/12 8:40 PM, "Byron Ellacott" <[e-mail]> wrote:
>>>>>
>>>>>> Indicate to the end user that it's not a native language?
>>>>>> Auto-translate?
>>>>
>>>> Murray has the right sense of what I meant, for both of these.
>>>>
>>>>>> Negotiate for native language with Accepts-Language, if indicated as
>>>>>> possible via a Vary header?
>>>>>
>>>>> That's HTTP layer stuff. We're talking about embedding multiple language
>>>>> tags in the response.
>>>>
>>>> Are we?  I thought draft-sheng-weirds-icann-rws-dnrd-01 sect. 7.3
>>>> suggested a single language tag for the entire response, with "possible
>>>> considerations" of multiple language tags.
>>>>
>>>> But, with this point, what I'm suggesting is that the user of a particular
>>>> client likely has one or a few preferred languages, which they could
>>>> potentially indicate to the server, in the event that the server has multiple
>>>> translations.  This would be applicable for mixed language responses as
>>>> well as single language responses, since it only indicates a client preference,
>>>> not a strict requirement.
>>>>
>>>> My primary perspective on this entire subject is that whatever mechanisms
>>>> or systems indicate language or language preference need to be optional,
>>>> and should support reasonable use cases for current or likely future operators.
>>>> I think there's a use case for language preference indication, as per below,
>>>> and I think Ning is suggesting a use case for tagging the language of an
>>>> entire response, inline in the response.  What are your (collective "your")
>>>> thoughts on how reasonable these use cases are?
>>>>
>>>>>> Some RDAP services will not support multiple languages meaningfully, but
>>>>>> there are existing whois services that provide (non-standard, varying)
>>>>>> ways to indicate a preferred language on query, with multiple language
>>>>>> options available for many response fields.
>>>>>
>>>>> Can you provide an example of one of these services so we can query it?
>>>>> That would go a long way in helping shape this need, I would think. Are
>>>>> there registries that collect contact data in multiple languages?
>>>>
>>>> $ whois -h whois.nic.ad.jp -- 'NET 113.32.19.157'
>>>> $ whois -h whois.nic.ad.jp -- 'NET 113.32.19.157 /e'
>>>>
>>>> $ whois -h whois.jprs.jp -- 'jprs.jp'
>>>> $ whois -h whois.jprs.jp -- 'jprs.jp /e'
>>>>
>>>> The data labels are sometimes translated, sometimes not.  In the native
>>>> language responses, there's often an English translation.  JPRS includes
>>>> an English help/info block even for the native language response.  I don't
>>>> know for sure if they collect the information in multiple languages, though
>>>> I think they do - any JPRS or JPNIC operators on the list to confirm?
>>>> Character set is ISO-2022-JP.
>>>>
>>>> I don't know if there are other services with such a switch mechanism,
>>>> either - we're all aware of how hard it is to find out what's actually done
>>>> out there on port 43 :-) - but for another comparison whois.kisa.kr returns
>>>> both native and english output, at least for "kisa.kr".  Character set is
>>>> EUC-KR.
>>>>
>>>>  Byron
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> weirds mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/weirds
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> weirds mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/weirds
>>>
>>
>> _______________________________________________
>> weirds mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/weirds
>