Line 16: |
Line 16: |
| | | |
| === Usage === | | === Usage === |
− | String text components are most commonly used to create empty or space-filling text components, which can then link multiple text components together using `appendSibling`. | + | String text components are most commonly used to create empty or space-filling text components, which can then link multiple text components together using <code>appendSibling</code>. |
| | | |
| == TranslationTextComponent == | | == TranslationTextComponent == |
Line 22: |
Line 22: |
| | | |
| === Format modifiers === | | === Format modifiers === |
− | Translation text components also support format modifiers like used in <code>String#format</code>. These format modifiers are declared by using the string <code>%s</code> when creating a translation entry for a given translation key. This format modifier will then be expanded and replaced with the provided object when rendered by the client. Any other format modifiers like <code>%d</code> or <code>%n</code> are ''not supported'' and will throw a formatting error. To get a normal percentage, a double percentage sign must be used (<code>%%</code>). The list of arguments to expand these are passed to the constructor of the <code>TranslationTextComponent</code> using an Object varargs parameter, similar to <code>String#format</code>. Any objects that are not an instance of <code>ITextComponent</code> will have <code>Object#toString</code> called during expansion. | + | Translation text components also support format modifiers like used in <code>String#format</code>. These format modifiers are declared by using the string <code>%s</code> when creating a translation entry for a given translation key. This format modifier will then be expanded and replaced with the provided object when rendered by the client. Any other format modifiers like <code>%d</code> or <code>%n</code> are ''not supported'' and will throw a formatting error. To get a normal percentage, a double percentage sign must be used (<code>%%</code>). A number can also be inserted, and it will be used as a 1-based index to select the argument. This is useful for choosing a specific argument out of order, or using the same argument twice. This looks like <code>%1$s</code>. The list of arguments to expand these format modifiers are passed to the constructor of the <code>TranslationTextComponent</code> using an Object varargs parameter, similar to <code>String#format</code>. The arguments passed in the constructor of a <code>TranslationTextComponent</code> can be either an Object or another <code>ITextComponent</code>. Any <code>ITextComponent</code>s will be expanded and have any declared <code>Style</code>s properties preserved in the final output. Any objects that are not an instance of <code>ITextComponent</code> will have <code>Object#toString</code> called during expansion. |
| | | |
| === Creating === | | === Creating === |
− | Translation text components are instantiated in the form <code>new TranslationTextComponent("your.translation_key.here", "thing1", "thing2")</code>. In your lang file, the entry would look something like: <syntaxhighlight lang="json">{ | + | Translation text components are instantiated in the form <code>new TranslationTextComponent("your.translation_key.here", new StringTextComponent("thing1").withStyle(TextFormatting.RED), new StringTextComponent("thing1").withStyle(TextFormatting.BLUE))</code>. In your lang file, the entry would look something like: <syntaxhighlight lang="json">{ |
− | "your.translation_key.here": "I like using %s and %s!" | + | "your.translation_key.here": "I like using %1$s and %2$s!" |
| }</syntaxhighlight> | | }</syntaxhighlight> |
− | In practice, when sent to a player, this would be displayed as <code>I like using thing1 and thing2!</code>. Note that any more values must be declared as comma-separated key-value pairs as required by the JSON specification, with the last key-value pair not ending with a comment. | + | In practice, when sent to a player, this would be displayed as <code>I like using thing1 and thing2!</code>, where <code>thing1</code> would be colored as red and <code>thing2</code> would be colored as blue. Normal <code>String</code>s can also be passed in, and they will inherit the <code>Style</code> object of the main text component. Note that any more values in the language file must be declared as comma-separated key-value pairs as required by the JSON specification, with the last key-value pair not ending with a comment. |
| | | |
| === Usage === | | === Usage === |
− | Translation text components are used for sending anything visual to the player. Using them provides a benefit of format modifiers and the ability to be translated into different languages. This means that, given a translator, one could translate the English translation file (by default, <code>en_us.json</code>) into another language for a given mod. This system is also used by Minecraft itself and has been used to translate the game into hundreds of langauges. Translation keys are also required for declaring the names of items and blocks in the game. | + | Translation text components are used for sending anything visual to the player. Using them provides a benefit of format modifiers and the ability to be translated into different languages. This means that, given a translator, one could translate the English translation file (by default, <code>en_us.json</code>) into another language for a given mod. This system is also used by Minecraft itself and has been used to translate the game into hundreds of langauges. Translation keys are also required for declaring the names of items, blocks, and entities in the game. |
| | | |
| | | |
| [[Category:Translations]] | | [[Category:Translations]] |