HULD improvements

[MishimaHaruna]

Hercules Ultimate Localization Design

• Fixes issues with nested function calls and the HULD template generator
• Improves the quality of the generated translation strings, allowing for some sentence structure variations (see below)
• Adds an option to let server administrators decide whether to hard-wrap or soft-wrap their scripts (see below)

Some highlights:

Added option to strip hard line-breaks from mes dialogs

• The \r character, in a mes dialog, is normally represented by the client as a hard line-break.
• Since a client may have different requirements in line lengths (for example using a font with different size or metrics), an user might wish to ignore hard-wraps and let the client automatically soft-wrap
  instead.
• If you want to hard-wrap (official default), keep the SCRIPT_MES_STRIP_LINEBREAK define commented out.
• If you want to let the client soft-wrap automatically (may work better for custom clients), uncomment it.
• Imprved HULD handling of \r (to avoid control characters in the generated file)
• Please note that this requires cooperation by script writers:
  • Each mes should contain one and only one sentence, possibly without using the '+' concatenation (but, rather, sprintf).
  • Two separate sentences (where a hard-wrap is required even for soft-wrapped text) should always go into separate mes commands.
  • Following the above two recommendations, also produces a better quality translations .pot file.

Proof-of-concept best scripting practices for HULD

• Note: This only edits one script (Parmy Gianino of the Alchemist quest), and it's an invitation to script developers to gradually update the other scripts following the same guidelines.
• mes strings are split by sentences: each string contains one and only one sentence. Line-break hints are specified with \r (and for readability the string is split in multiple lines with parse-time concatenation, without using the '+' operator)
• When sentences need concatenation (variable names or values), sprintf or mesf are used, so that the generated translatable string is still one and only one. When using sprintf, the _() or _$() macros are used, to mark the string as translatable. For format strings, use _$() and for normal strings use _(). When using mesf, no additional action is necessary.
• select() / prompt() entries are in separate entries, separated by commas, where possible (it makes their translation easier)
• This makes it easier to translate NPCs to languages with different sentence ordering (and with longer or shorter sentences). In the generated .pot, sentecnes will no longer span across several strings.
• Replaced hardcoded item names with getitemname()

[ghost]

THANKS GOD -

[ghost]

will it allow us to translate npc display names as well? 😍

[dastgirp]

Not yet @EPuncker, you cannot change display name yet..

[MishimaHaruna]

Good point about the NPC display names. We can do something about it, but there will be limitations:

• The command setnpcdisplay() would invalidate the translations. If a script uses that to change a NPC name, the name would be set the same for every language, without translations.
• If we want the NPC names to use the per-player language settings (instead of the global server-wide language setting), there are some packets that would become less efficient. This needs some further research.
• Commands such as donpcevent() or enablenpc() would still use the original name, not the translated one (not really a limitation, more like a design decision to keep things sane).
• Whispering (NPC:Npcname) to trigger OnWhisperGlobal would still require the original name, not the translated one.

[ghost]

already going to buy poedit pro in order to full translate my server 😍 I'm so excited lol

[botka4aet]

I added generate-translations and map-server restarts after fully loaded.

[Cyanide0210]

@botka4aet just move generated-translations.so out from plugins folder but I guess you figured it out by now.

Just leaving a comment for reference.