How to configure the MU Online client language system

Configuring the MU Online client language system is one of those tasks that seem simple at first glance and reveal layers of complexity as soon as you open the first file. For the player, the difference is huge: a fully Portuguese client, with translated interface messages, item names, tips and warnings, conveys professionalism and welcomes those who do not know English, whereas a half-translated client, with broken accents and half-finished sentences, gives the impression of amateurism. For the administrator, the challenge lies in understanding that the text the player sees on screen does not come from a single place. It is scattered across interface files, item definitions, system messages and, in some cases, inside the game executable itself. Localizing a client is, in practice, a job of organized prospecting: finding out where each text lives, editing it while respecting the correct encoding and ensuring that the font used can draw the Portuguese characters. This tutorial is aimed at the intermediate-level administrator who wants to deliver a consistent localized experience. As always in the world of emulators, the file names, folders and structure vary by season and by client, so treat the examples below as an illustration of real concepts, not as a literal copy for your package.

Prerequisites

Before starting to translate, prepare the environment to work safely and without rework. Localization touches many files, and a minimum of initial organization keeps you from getting lost along the way.

• Backup of the client folder: copy the entire folder, paying special attention to the subfolders that contain texts, such as Data, Local or Text, depending on your package.
• A text editor with encoding control: you need an editor that shows and lets you choose the file's encoding, such as ANSI, UTF-8 or the specific encoding your client uses. Editing without controlling the encoding is the number one cause of broken accents.
• A BMD editing tool, when applicable: in some seasons, the texts are packed into BMD files and require a compatible tool to open and save them.
• A font with accent support: if the client uses bitmap or embedded fonts, you need to make sure they contain the accented Portuguese characters.
• A test client: never translate directly in the production client. Work on a copy and validate before distributing.

Where the client keeps its texts

The first step of any localization is mapping: understanding where each type of text is stored. In MU Online, the text is spread across a few very distinct sources, and each one requires different handling. Understanding this division keeps you from translating the same text twice or leaving whole areas untranslated.

The most common source is the interface text files, which hold buttons, menus, window messages and warnings. They are usually plain or BMD files inside a dedicated folder. The second source is the item and skill definitions, where the names that appear over objects on the ground and in inventory lists live. The third source is the system messages, those notifications that appear in chat about events, commands and errors. And the fourth source, the most stubborn, is the text embedded in the executable, strings that the original developer baked into the binary and that can only be changed with resource-editing or binary-editing tools.

The sensible strategy is to attack from the easiest source to the hardest. Start with the interface and the system messages, which tend to be editable text files and deliver the most visual impact with the least effort. Leave the executable texts for last, because they are the riskiest and not always worth the trouble.

Character encoding: the heart of localization

If there is one concept you need to master before any other in this task, it is character encoding. All text saved to disk is, in fact, a sequence of bytes, and the encoding is the rule that says which bytes represent which letters. English lives comfortably within the basic ASCII range, but Portuguese needs extra characters like á, ã, ç, é and õ, which fall outside that basic range and depend on an encoding that represents them correctly.

The classic problem happens when the file is saved in one encoding and read in another. The client reads the bytes expecting ANSI, for example, but you saved in UTF-8, and the result is that each accent turns into two or three strange symbols. To fix it, you need to find out which encoding your client expects and configure your editor to always save in it. Many MU clients use a specific code page encoding instead of UTF-8, so do not assume UTF-8 is always the answer. The safe path is to edit a known text, save it in one encoding, test it in the client and see whether the accents show up correctly; if not, try another encoding until you get it right.

Example of accents broken by the wrong encoding:
  Expected:  Poção de Vida Grande
  Broken:    Poção de Vida Grande
  Broken:    Po??o de Vida Grande

The fix is to save the file in the encoding the client expects,
not in the editor's default encoding.

After getting the encoding right, there is still the font. It is no use having the file correctly encoded if the font used by the client does not draw the character á. In clients that use bitmap fonts, you may need a font that contains the full set of accented Latin characters. This is a point that varies quite a bit by season and client, so test with a sentence full of accents to confirm that the font covers everything.

Step by step: translating the interface

With the mapping done and the encoding understood, let us get to the practical work of translating the interface, which is where the player feels the difference most. Follow this order to stay in control.

1. Locate the interface files. Identify, within the client's text folder, which files control menus, buttons and windows. Open them one by one to understand what each file covers.
2. Make a reference copy. Before translating, keep a copy of the original English file. It will serve for comparison in case something goes wrong.
3. Translate while preserving the structure. Many MU text files follow a key-and-value format, or numbered lines. Translate only the visible text, never the keys, the line numbers or the formatting markers.
4. Respect the space limits. Buttons and boxes have a fixed size. A translation that is too long can overflow the space and get cut off. Prefer concise terms when space is tight.
5. Save in the correct encoding. Every time you save, confirm that the editor is using the encoding the client expects.
6. Test in the client. Restart the test client and navigate through all the screens you translated, checking accents, text cutoffs and consistency.

ILLUSTRATIVE example of an interface file in key-value format
(the real syntax varies by season and client):

  BTN_LOGIN    = "Entrar"
  BTN_CANCEL   = "Cancelar"
  MSG_WELCOME  = "Bem-vindo ao servidor!"
  LBL_LEVEL    = "Nível"

Translate only the text between quotes. Never change keys
like BTN_LOGIN, since the client uses them internally.

Care with markers deserves special attention. Some messages contain variables, represented by symbols like %s or %d, which the client replaces in real time with a player's name or a number. You may move the position of that variable within the sentence to respect the natural order of Portuguese, but you can never delete it, because without it the message loses the information it was supposed to show.

Translating item names and system messages

After the interface, the next highest-impact target is the item names. They appear on the ground when an item is dropped, in NPC shops and in the inventory, so a careful translation here is very visible. Item names usually live in the client's item definitions, and the main care is to keep the correspondence with the server: you translate the text that appears, but the item ID, that category-and-index pair, stays untouched. Translating the name should never change the item's technical identity.

System messages follow the same logic as the interface, with the difference that many of them carry variables. Messages like event warnings, command results and error notifications need to be translated with extra attention to the embedded variables. A good practice is to translate while keeping the tone of the game: event messages can be more excited, error messages should be clear and direct. Terminology consistency also matters a lot: if you translated Warp as Teleporte in one place, use Teleporte everywhere else, so as not to confuse the player with synonyms.

Dealing with text embedded in the executable

We reach the thorniest part of localization. Some texts are not in any editable file, but rather baked into the client executable. They are messages the original developer left fixed in the binary, and changing them requires resource-editing or hex-editing tools, plus much greater care, because a mistake in the executable can prevent the client from opening.

The recommendation for the intermediate-level administrator is pragmatic: assess whether it is worth it. If the embedded texts are few and barely visible, it is often better to leave them in English than to risk corrupting the executable. If you decide to touch them, the golden rule of binary editing is that the translated string cannot be longer than the original, because the space reserved in the file is fixed. You can shorten it or use the same number of characters, but exceeding the limit breaks the binary's alignment. Back up the executable before any change and test immediately after each one, because a client that will not open is the worst possible result of a translation session.

Synchronizing the language with the server

Not every text the player sees comes from the client. An important part of the messages is sent by the server in real time: global warnings, automatic event messages, command responses and system notifications. There is no point in translating the whole client if the server keeps sending warnings in English. That is why a complete localization also involves reviewing the messages configured on the server side.

The point to watch here is encoding again. The messages the server sends must reach the client in the encoding it expects to draw, otherwise the accents break even with the correct text. Coordinate both sides to use the same encoding. For those building the infrastructure from the beginning and wanting to understand where these server settings fit in the whole, the guide on how to build a MU server from scratch helps situate the system messages within the project's overall architecture.

Common errors and fixes

The table below gathers the problems that most often come up when localizing a MU client and the path to solving each one. Consult it whenever a text does not behave as expected.

The diagnosis of most of these cases begins with a simple question: is the text wrong or is the text missing? Wrong texts, with broken accents, are almost always an encoding or font problem. Missing texts, which are still in English, are a mapping problem, meaning you have not yet found the file where that text lives.

Translation maintenance best practices

A translation is not a project you do once and forget. With every season update, new files appear and texts move around, so it is worth keeping a process. Always keep a copy of the original English files alongside the translated ones, which makes it easier to identify what changed in a new version. Keep a glossary of terms, a simple list that fixes how each game term should be translated, ensuring that Warp is always Teleporte and Set is always Conjunto, for example.

Also document which files you have already translated and in which encoding, so that anyone who continues the work knows exactly where to make changes. And version your translation packages: every time you release a batch of localized texts, keep that set with a version number, so you can revert if an update breaks something. This discipline turns localization from a one-off effort into a project asset that stays healthy over time.

Launch checklist

Before distributing the localized client to players, go through this list. Each checked item reduces the chance of a player finding broken text.

• Full backup of the client done
• Correct client encoding identified and tested
• Font with accent support confirmed
• Interface files translated and tested
• Item names translated without changing the IDs
• System messages translated with variables preserved
• Executable-embedded texts assessed and, if edited, tested
• Server-side messages translated and in the correct encoding
• Terminology checked against the project glossary
• All screens navigated looking for cut-off or missing text
• Translation package versioned
• Control document of translated files updated

By following this flow, you deliver a localized experience that respects the Portuguese-speaking player and gives the impression of a careful project. Remember that everything here is an illustration of real concepts, and that the file names, folders, encoding and structure vary by season and client, so adapt each step to your specific package and always validate in a test environment before distributing to the community.

Frequently asked questions