|
Great ideas but all of these prevent a third party from doing a translation.
Bret
Sent from my Commodore 64
Hi,
I learned the email below from Paul got rejected by the mailing list due to
transition of their membership from iSIGHT to FireEye and I am forwarding
his very informative email.
Regards,
Ryu
JSON-LD specifies a number of different ways to handle internationalized strings including supporting more than one language.
Using the same technique that the CTI TC voted on late last year to not disallow for Object Ids as URIs, you could make limited use of JSON-LD to
address this.
The simplest way would to specify a context that defines the default language. The downside to this approach is only 1 language can be supported
and every ‘string’ value in the original document would need to be translated, thus losing the original text. The upside is that developers don’t need to worry about language support.
“description”: "忍者",
}
A
potentially better solution is to use language maps where the map can support more than one language. The downsize of this approach is that every key who’s value needs to be translated must be defined in the context as a container for language.
{
“description”: { “@id”: “description”, “@container”: “@language” }
While this provides developers an easy way to have programmatic access and it supports the ability to specify more than one language,
It does make simple things more complex for environments where only a single language is to be supported.
A hybrid of this that was done in the TC for handling timestamps with precision or the use of a controlled vocabulary value, might be where the language
specifier would only be required when a language other than “en” is specified (en is the default unless we define a way to specify the default language):
“description”: {“value”:
"忍者",
“language”:”ja"}
The big drawback with this approach is that now the fields that are translatable must be defined as arrays.
I think the language maps approach, whether you use the ‘@context’ or not is actually a lot simpler for developers, is FAR LESS complex than using
relationships to create translated objects, and build natural support for internationalization into the JSON MTI binding in a consistent manner that developers can easily understand regardless of the programming language they use.
Hopefull this helps you better understand the JSON-LD possibilities and perhaps gives others a new perspective on possible alternative approaches.
iSIGHT Partners, a FireEye Company
|