Custom localization properties

About every property in the "Properties" list for custom localization definitions at Configurazione^.json.

Since 1.3:0 version you can adjsut them all in the Settings window with enabled option "Show advanced":

Looking at the definition named "Example":

  1. Keywords Directory: (Retelling the explanation about Fallback localization) this path is responsible for loading the values of the keyword names from Bufs*.json files and their descriptions from BattleKeywords*.json files, as well as skill tags from SkillTag.json. Program searches files by patterns "*Bufs*.json", "*BattleKeywords*.json", and "*SkillTag.json" as universal option for prefixes (Files at LimbusCompany_Data\Assets\Resources_moved\Localize marked with EN_ / KR_ / JP_) and postfixes (-a1c2p3 / _personality-01 / etc). It is also taken from this folder:

    1. "Atk Weight" for Skill names displaying (MainUIText_UPDATE_ON_0720.json file, mainui_target_num_label id).

    2. "Uptie Tier" for Skills navigation panel Uptie switch buttons (Filter.json file, filter_awaken_state id).

    3. "View Desc." text for E.G.O Gifts UI (MirrorDungeonUI_3.json file, mirror_dungoen_ego_gift_history_view_desc id).

  2. Keywords Autodetection Regex Pattern: this option should be left untouched unless you have a need for the Keywords Shorthands Regex Pattern from the next option №3. Responsible for the algorithm by which keywords should be automatically detected and highlighted in the text. In this link you can see how it works using the keyword "Discard" as an example: https://regex101.com/r/9i5nUF/1.

    1. Basically it says (Translated from Regular Expressions language, which at first glance look like a random set of characters): "The name of the keyword and anything right after it except the following characters: any other language characters (\p{L}), open/close square bracket (\[ and \]), regular closing bracket (), used because in Korean localization view the keyword "Discard" was often falsely automatically highlighted in brackets where actual meaning of it was "(Rounded down)"), dash (\-), underscore (_), less than (<), single and double quotes (' and "), colon (:), plus (+)".

    2. It seems like this was added, because before Season 3, localization did not highlight keywords in the text (They were just words in the text without any highlighting) and it was necessary to highlight them all. Now this puts a bit of a stick in the wheel, and it is explained below.

    3. These conditions are used by official localizations to prevent keyword highlighting where it's not needed. For example, "Hardblood[TabExplain]" in the passive skill "Bloodfeast" of The Manager of La Manchaland Don Quixote (ID 1031001 in EN_Passives.json), where part of the string "When using 'Variant Sancho Hardblood Arts 6 - Whip'," contains a name potentially matching the keyword "Hardblood" for BloodArmorPersonalityFirst ([TabExplain] is an empty string skill tag that just inserts nothing).

    4. Or as another recent example with N Corp. E.G.O::Contempt, Awe Ryōshū, they used <noparse> tag instead: "Combat Start: N Corp. E.G.O::<noparse>Fell Bullet</noparse> Yi Sang's ..". It satisfies condition about less than (<) character after word, which is probably more aesthetic than just [TabExplain] (Update after MOWE BokGak about <noparse>: this caused a problem in highlighting keywords in Cassetti in skills, where the tag was not placed after the "Hardblood" keyword, which is why the full keyword entry from the TextMeshPro tags was displayed there ("stick in the wheel"). You've probably seen it).

      1. Illustraions about the MOWE BokGak Cassetti Skills incident:

  3. Keywords Shorthands Regex Pattern: this is a special replacement for the normal [KeywordID] keyword highlightion with a modifier that allows you to change the keyword name (And optionally color) and not* have it turn into Unknown in the program's text preview, like Limbus likes to do if (Skills and Passives localization files only) there is no status effect ID or skill tag ID in the square brakets. And, speaking about the previously mentioned connection with Keywords Autodetection Regex Pattern: the pattern is modified by adding a character to the general list to ignore the end character of the keyword name. In the example, this is the ` character, as it is technically equivalent to the < character, which is mentioned in the warning below (Without it there are will be a false autodetection of keyword within Shorthands writing that will be look like "[Sprite][Sprite]Keyword name").

    1. It is also important to note that the parts of the pattern "?<ID>\w+", "?<Name>" and "?<Color>" should not be changed, they are used by the program to get values of the Regex match groups and also at the syntax highlighting compilation where part "?<ID>\w+" is being replaced with every loaded keyword ID to add highlight definitions.

Example shorthands view

But keep in mind that Limbus itself does not support Shorthands by default, and if you write this in the Skills/Passives localization files and not convert them at final, it will turn into Unknown in Limbus. For them, you need to use a special converter that turns this short entry into a full deployment of Unity TextMeshPro tags: [Charge:`Alternative name`] from screenshot technically equals to <sprite name="Charge"><color=#17dfd7><u><link="Charge">Alternative name</link></u></color> TextMeshPro expression with rich text tags (@ "this is the ` character, as it is technically equivalent to the < character" from keywords autodetection explaination above). Only such text can be properly understood by the game (And its size explains the existence of Shorthands; P.S. you can also write these TextMeshPro versions of keywords in the program's text, the same conversion process occurs inside the program to give them the appropriate appearance in the preview).

  1. Keywords Shorthands Contextmenu Insertion Shape: it is also linked to Shorthands; in the context menu on the right mouse button in the text editor there are buttons "... to Shorthands", the result of which is determined by this property. All "<...>" of insertion is Neccessary:

    1. The "<KeywordID>", "<KeywordName>", "<KeywordColor>" ("<HexColor>" from option below too) also should not be changed because exactly them is being replaced with actual values at the moment of context menu option clicking.

  2. Keywords Shorthands Contextmenu Insertion Shape <KeywordColor>: relevant part of fourth option to insert instead of "<KeywordColor>". At the Example option it written as "(<HexColor>)" which equals to (If color is not default for keyword or/and not empty):

    1. [InsertedID:`InstertedName`]<KeywordColor> -> [InsertedID:`InstertedName`](InsertedColor).

  3. Keywords Multiple Meanings Dictionary: creation is explained at the 1.0:3 release https://github.com/x1bViolet/Limbus-Localization-UI/releases/tag/LCLI1.0.3. It is needed for use in an options "Unevident to ..." from context menu to take into account not only the default keyword names. As example consider also "Ruptures" or "Poises" words for 'Burst' and 'Breath' keyword IDs (This is difficult to translate into English from Russian, because in English there are not many possible different endings of words based on position in text. And that's why there's no need for this thing in (almost?) all other languages).

  4. Context Menu Extra Replacements: special dictionary with Regex patterns and substitutions can be used for fast translations of repetitive parts of the text by type "Inflict +digit [Vibration] Count" and etc. See detailed desctiption and guide in Context Menu Extra Replacements.

  5. Keywords Sprite Vertical Offset: sets keyword sprites vertical offset, need to be adjusted if keyword sprites are too low or high with specified font.

  6. Keywords Sprite Horizontal Offset: same purpose.

  7. Title/Context Font: determines the font to be used for names and descriptions.

  8. Title/Context Font (Override Read Name): this option is intended for rare cases where a font for some reason refuses to load normally even if path is correct. The solution is to specify the "True" font name for reading (Since in C# WPF, font loading occurs via 'Font("file:///...path/font.ttf", "./#Fontfamily name")'). It exists because this rare case occurred with the kotra bold Title font for the original Korean localization definition, where its internal name is 'KOTRA_BOLD' (Even if you open the .ttf file and check), but font loads normally if its name for reading at "./#Fontfamily name" changed to "KOTRA BOLD" without the underscore. Magic.

  9. Title/Context Font (Font Weight): this is a font weight.

  10. Title/Context Font (Font Size Multipler): if the font looks too small/big.

PreviousBase setupNextProgram behavior and features

Last updated