Description

The TransformedContentExtension class implements the transformed content extension defined by RFC6497. Between it and UTS35, there is no extension information available about what should be considered valid outside of those explicitly mentioned in the data files, which clearly are not exhaustive, as references to vendors, etc, are made in the RFC but not in the data files. A tag will only be considered strictly correct if its values match those found in the data files (cldr/transform*.xml), and otherwise be rejected, unless found in the -x0 private use subtag.

Dates can be used, but must be the final subtag and will be in the format of YYYY, YYYYMM, or YYYYMMDD.

Accessing / manipulating extension subtags

The TransformedContentExtension tag provides several methods to access the information provided in it. These methods in the future will return objects that allow for greater manipulation of them. To guarantee future compatibility (because it is planned), use .List on results, as the List coercion method will return the raw tags (similarly, the Str conversion will eventually insert hyphens).

• .origin-language

  The origin language represents the source language that the main tag was transformed from. If Nil, it means that there was no language transformation.

• .hybrid-language

  The hybrid language is one that is mixed in with the main language of the language tag. A common example would be Spanglish, where the main tag is en and the hybrid-language tag is es. Based on TR35, the source of the hybrid language in the language tag is either the transform origin language (the tags immediately following the t- singleton) or the tags following the h0- mechanism tag. The decision is currently made based on whether the subtag following h0- is hybrid. If so, returns a language tag for the transform origin language, and if not, uses the subtags after h0- In this way, the tags en-t-h0-es and en-t-es-h0-hybrid are effectively equivalent and would return the same language tag.