RE: [cti] i18n (RE: MVP Discussion) - An Updated Proposal

["Masuoka, Ryusuke" <masuoka.ryusuke@jp.fujitsu.com>]

Hi, Bret,

> Also, string fields will not be used for automated processing, but rather for human consumption.

String fields are for human consumption, but there are many things enabled if language 
information is properly available. Pick a particular language text to display based on 
user preference (ex. in ja, in en if ja is not available, then in its original language if both ja and
en are not available.) 

> I think we can get light years ahead of where we are today with 
> just a top TLO level lang tag and not a Lang tag on each string field.

I think we can get light years ahead of where we are today with just a Lang tag on each string field
and not a top TLO level lang tag :-)

Being serious, it was not my initial plan to come forward in the discussion and I did not expect 
so much cycles on CTI ML to be used. I am pleasantly surprised that i18n can be a topic
of so much interest. The discussions helped me a great deal to understand the issue 
really deep. One thing I do not understand, however, is that there seemed to be a deep-rooted 
objection against "lang tag on each string field". Making text fields self-contained will be 
simpler and an enabler for many things (here already and to come) and dependence on 
object structure will, I am afraid, limit utility and flexibility of i18n. 

Regards,

Ryu

-----Original Message-----
From: Jordan, Bret [mailto:bret.jordan@bluecoat.com] 
Sent: Tuesday, April 26, 2016 10:48 AM
To: John-Mark Gurney
Cc: Masuoka, Ryusuke/益岡 竜介; Wunder, John A.; Mates, Jeffrey CIV DC3/DCCI; cti@lists.oasis-open.org
Subject: Re: [cti] i18n (RE: MVP Discussion) - An Updated Proposal

Another thing to keep in mind is the language does not need to try and solve the data quality issue.  Also, string fields will not be used for automated processing, but rather for human consumption. 

I think we can get light years ahead of where we are today with just a top TLO level lang tag and not a Lang tag on each string field.

Bret 

Sent from my Commodore 64

> On Apr 25, 2016, at 6:16 PM, John-Mark Gurney <jmg@newcontext.com> wrote:
> 
> Masuoka, Ryusuke wrote this message on Mon, Apr 25, 2016 at 10:21 +0000:
>> Hi, John, Bret,
>> 
>> -----
>> Use Case (1) Second Paragraph
>> -----
>>> Or another use case is the CTI provider in Japan writes a CTI file 
>>> with its title in English and description in Japanese. This is 
>>> because many Japanese can read short English titles, but many 
>>> Japanese have difficulties to understand long and detailed descriptions in English.
>> 
>> In the above case, I am talking about is something like the following.
>> 
>> -----
>> {
>> "type": "package",
>> “indicators": [
>> {
>>   "type": “indicator",
>>   "id": "indicator--a1201df6-c352-4a81-9c7c-5a6f896a4e31",
>>   "revision": 1,
>>   "created_at": "2015-12-03T13:13Z",
>>   "created_by_ref": "identity--69a17e1b-bb45-4657-9a9d-96db3faccdde",
>>   "title": {“en”: "Dridex Campaign - Botnet 121"},
>>   “description": {“ja”: "ボットネット 121 を活用する Dridex を元にしたキャンペーン"}
>> },
>> ...
>> }
>> -----
>> 
>> It is often the case for academic papers that we (Japanese) provide 
>> its title and abstract in English, but its main body in Japanese.
> 
> I would say that the lang id is not the language of the text, but who 
> it is intended for..  If the "Japanese" translation happens to be in 
> English, then that is fine to label it was jp if that is the way they 
> want it presented...
> 
> So, your example would have jp as the language for the title too..
> 
> There wouldn't be anything that would prevent someone creating a new 
> translation object that completes the jp translation of the title...
> 
> I do like the proposal of being able to override the lang on a per 
> field basis, but IMO, unneeded, per above.
> 
> Another way to state it is that the lang id field is who to present 
> the text of this object to...  If you speak jp, then present these 
> fields to them, etc.  It seems odd/crazy that we should allow an 
> object to be created where different parts of the object are not 
> present for which we need to present it to the user of that language...
> 
> In your example, is there a reason the program needs to know that the 
> en title is in English?  It clearly doesn't need the info for 
> rendering it, as that is already encoded via the Unicode characters..
> 
> Thanks.
> 
> --
> John-Mark