How To Change Language Hoi4

[Kayla Munl]

Thelocalisation is stored within the /Hearts of Iron IV/localisation/ folder, in which any sub-folder can be used. Each file is assigned a language with its filename by adding it in the end, with the following languages existing:

The filename has to contain the language's internal name as the file will not be loaded otherwise.

The currently-enabled language is chosen within the user directory's /Hearts of Iron IV/pdx_settings.txt file, however, more languages cannot be added directly other than these listed languages.

Localisation is created within any file in the localisation folder: the filename aside from the file extension is irrelevant aside from deciding which language is chosen.

Every localisation file must use the UTF-8-BOM encoding, i.e. the UTF-8 encoding with the byte order mark in the beginning of the file. Exact details depend on the text editor:

Each localisation key must be assigned to a language database, marked with a line containing the language name ending with a colon, and nothing else. For example, l_english:. Until the next database entry or the end of file, this will assign every localisation key afterwards to the English language. A single file may contain entries for databases of multiple languages at the same time, however the filename must also contain each of these languages.

Any issue with localisation, such as special characters or spaces in localisation keys or a missing quote, will break the localisation file starting with the point where the syntax first stopped being followed correctly.

Nearly any printable character is allowed to use within the localisation value, other than certain special characters with special meaning, such as square brackets, or newlines. However, only some select characters are present in the fonts that are used in the game, and the selection of characters differs depending on the font. If the used font doesn't include a representation of a character, the game will replace it with a question mark (?). This affects only the font representation: this may be remedied by switching the used font within the interface or by changing the font to include the letter.

Typically, localisation key overlap must be avoided, overlap being the same localisation key being defined several times in the same language's files. This is tracked within user directory's /Hearts of Iron IV/logs/text.log file, which contains a list of overlapping localisation keys if any. The value that'll get chosen does not seem to have a consistent pattern, but seems to prioritise base game files.

However, if the localisation file is contained within a folder with the name of "replace" (such as /Hearts of Iron IV/localisation/english/replace, still must be inside of localisation), it will get priority over the entries that are not. This can be helpful to overwrite only specific localisation keys without porting over the entire file, such as if the file gets frequently updated in base game.

For example, if desiring to change the name of the effect to add political power from the default POLITICS_ADD_POLITICAL_POWER:0 "Political Power: $VAL=+0$.", it may be undesirable to port over the entire /Hearts of Iron IV/localisation/english/effects_l_english.yml file to the mod, as new effects frequently get added to the game which would mean the file has to be kept in check.

However, instead creating a new localisation file within the /Hearts of Iron IV/localisation/english/replace/ folder and defining the POLITICS_ADD_POLITICAL_POWER localisation key there will result in the value of the key getting changed without needing to copy the entire localisation file, meaning that the mod is now easier to port to future updates.

Various characters can be added to a string to alter its colour in-game. A colouring character formatting begins with a section sign () and includes a single letter (byte) afterwards used to identify the colour. The exclamation point is used to mark the end of a colouring rule. The end of a string doesn't necessarily mean that the colouring rule will end, meaning its use is mandatory with every colouring rule to avoid spillover into the next text, even if it should last until the end of the string. On Windows, the Alt+21 alt code can be used to input a section sign.

New text colours can be added by expanding the textcolors = ... array in /Hearts of Iron IV/interface/core.gfx. Colour keys cannot have more than one letter (i.e. "BU = 0 255 0"), and will attempt to overwrite another colour key with the same first letter. It is also possible to make a colouring character represent a different colour from default when a certain font is used within the bitmapfont definition of that font.

Searching can be done using a text editor with the "Find in Files" functionality. Windows Explorer cannot be used, as it does not search inside of YAML files. For example, this is how the functionality is accessed in the more common editors to use:

Variables have a unique way for applying colouring, also allowing extra formatting characters. These are applied after a pipe placed at the end of the variable's name, such as [?my_variableR] that will turn the colour of the variable my_variable red. If no colouring is applied, it will use the same colour as regular text: the -colour block, textbox's text_color_mode, or the font's default colour in that order.

Any unrecognised symbols will neither change how the variable is localised nor get recognised as an error in-game. For example, it's common practice in the base game to prepend a dot before the digit used to control the amount of displayed digits as [?var.1]. In case of overlap between mutually-exclusive rules, the last-used one will be prioritised. However, static colouring has a lower priority than dynamic colouring (e.g. [?var+Y] will be treated as [?var+]), and using %% will also override %.

Within these examples, the first string depicts the current scope's democratic popularity as a percentage multiplied by 100 (%), in green (G), rounded to a whole number with 0 decimals (0). The second string displays the my_modifier modifier token's value as a 'good' number (+ making it green if positive, red if negative), with a percentage sign appended in the end (%%) and rounded to a number with one decimal (.1). The third string displays the variable in yellow colouring (as is common in the base game's tooltips), leaving it unchanged otherwise.

The following in localisation will display the default, /Hearts of Iron IV/gfx/flags/TAG.tga, flag of a country: @TAG

It's recommended to use the GetFlag namespace when possible instead, however, this can be used on localisation that doesn't support namespaces, such as custom modifier tooltips or the game rules.

If the sprite of the text icon is made out of multiple frames, then the specified frame can be used in localisation as icon_name1, this example being the first frame. Note that legacy_lazy_load = no is necessary for multi-framed text icons to work properly.

Namespaces refer to obtaining certain information from some scope to display in localisation. For example, getting the name of a country, the surname of a character, the ID of a state, and etc.

A namespace is marked with the square brackets on either side as in my_localisation_key: "[GetDateText]". By default, there is no scope assumed. A scope can be added, separated from the namespace with a dot, in order to let the game know from whom to obtain information, such as my_localisation_key: "[QAT.GetRulingParty]", which'll result in the ruling party of the country QAT appearing in localisation. Any dual scope that can be used as a target may be used in localisation. THIS can be used in order to refer to the scope of where it's used, such as effect_tooltip: "[ROOT.GetNameDefCap] declares war on [THIS.GetNameDef]".

Variables and event targets can be used within namespaces as well. For example, this grants the name of the capital state of OMA using the 'capital' variable: my_localisation_key: "[OMA.capital.GetName]". A list of built-in variables that can be used can be seen in the respective wiki page. Another common ones to use include 'owner' and 'controller' for states, such as my_localisation_key: "Owner of South-West England: [123.owner.GetName]".

Characters only exist within the scope of the country where they're recruited, in versions prior to 1.12.8. What this means is that before scoping into the character, one must first scope into the country that they are assigned to, such as current_name_of_fdr:0 "[USA.USA_franklin_delano_roosevelt.GetFullName]". If the character is marked with some other token (such as THIS or ROOT), this is unnecessary, but it is necessary for direct character IDs. Characters also support scoping to the GetLeader localisation function beforehand, such as leader_pronoun: "[ROOT.GetLeader.GetHeShe]" In this case, scoping into the country is still necessary.

Note that namespaces cannot be used everywhere. In the majority of the user interface, such as the names for wars or countries, they will not work properly, instead appearing exactly as in localisation, with the square brackets still visible. A list of locations where namespaces do work is:

The list may be incomplete, so something not being mentioned does not necessitate that localisation does not work there, but that does make it unlikely. Other localisation functions, not involving square brackets, do still work in this case, however.

Sometimes, the result of a function may be interpreted as a localisation key itself, but only if the string consists entirely out of that function. For example, log = "[THIS.GetTag]" will result in the non-ideology name being logged instead if one exists, since that localisation key consists only of the country tag. However, log = "loc_key_[ALB.GetTag]" will log loc_key_ALB, even if a localisation key exists with that name.

Useful for advanced abstraction techniques, as it can be used to approximate arbitrary string interpolation in Meta effects by applying to token variables which reference dummy objects, such as empty ideas, for which arbitrary localisation strings have been defined. Being able to pass around token variables that resolve to localised dummy objects is the closest it is currently possible to get to passing around and manipulating strings directly. This can enable all sorts of useful tricks and techniques, and you can even concatenate two dummy token's localisation values to form a new token string which is then pasted into a token variable in a Meta effect (as long as the resulting token string is in fact a valid existing token, otherwise the result is just an integer 0). In effect, this lets you derive a previously-unknown token variable from another already-known token variable, according to a template provided by another already-known token variable, provided the destination token is some prefixed or suffixed templated variation of the source token.

3a8082e126