Multiple Language Support

[dgovil]

Description of Proposal

This proposal adds a human language local to USD so that content may be localized or provide hints for assistive technologies.

Link to Rendered Proposal

Disclaimer

This proposal isn't representative of upcoming functionality in our products. This is a future looking proposal that seemed timely to augment the proposals by others here like Autodesk.

This builds on discussion in Issue 49

Supporting Materials

An example

def Foo(
    prepend apiSchemas = ["LocaleAPI"]
    language = "en_US"
) {
    string text = "There's a snake in my boot"
    string text:fr_CA = "Il y a un serpent dans ma botte"
    string text:hi = "मेरे जूते में एक सांप है"
}

Contributing

• [X] I agree to and accept the Supplemental Terms.

[PierreWang]

I understand the usage of this language id now. The proposal looks good to me. I have one suggestion for the fallback behavior. In my opinion, if an attribute doesn't specify a language, it is a fallback for any language. Its language can be inferred by the runtime or the system locale, but we also need to allow the user know that it is a fallback.

For example, def foo { string text = "Colours are awesome" string text:en_us = "Colors are awesome, but the letter U is not" string text:fr = "La couleur est géniale" } The first attribute is the fallback attribute, and the language may be inferred as "en_gb". If the user want to display the text in language "ar" (Arabic), it may not find a suitable attribute. In that case, it should be able to know that the first attribute is the fallback one. So GetLanguagePurposes may return a map which contains: (fallback, foo:text) (en_gb, foo:text) (en_us, foo:text:en_us) (fr, foo:fr)

[dgovil]

Ah yeah that makes sense. I'll add in the wording accordingly.

[meshula]

@PierreWang I think the comment from Dhruv in the other thread ran along the lines of "we can't infer based on codepoints because of ambiguity". When you say en_gb can be inferred, I think you mean that it can be inferred from system locale. I don't think it makes sense that the default fallback is the language of the system locale. If I wrote my default text in England, and you read it in France, the text did not become French because you opened it in another country :) I propose that en with no regional suffix should be the standard fallback, if the language attribute was not specified.

[spiffmon]

@PierreWang I think the comment from Dhruv in the other thread ran along the lines of "we can't infer based on codepoints because of ambiguity". When you say en_gb can be inferred, I think you mean that it can be inferred from system locale. I don't think it makes sense that the default fallback is the language of the system locale. If I wrote my default text in England, and you read it in France, the text did not become French because you opened it in another country :) I propose that en with no regional suffix should be the standard fallback, if the language attribute was not specified.

Just plussing that, in case @PierreWang meant infer from the text itself... if the text were instead "Lorries are awesome", it's not reasonable for a DCC to infer that's en_gb even though it is...

[dgovil]

Thanks for the feedback, @cookiecrook and @spiffmon . I've made the changes accordingly