Why MMEX Could Crash When Creating a Database in French
Posted November 8, 2026 by MMEX ‐ 4 min read
A recent bug in MMEX 1.9.4 showed how a seemingly harmless translation change can break database initialization. Here is what happened, why it happened, and how it was fixed.
A recent issue reported against MMEX 1.9.4 looked like a serious database or application crash.
When creating a new database, some users found that MMEX became unresponsive and had to be terminated manually. Opening a second database could trigger the same problem.
The issue was eventually traced to something much less obvious:
a duplicate currency name introduced by a French translation.
This is a good example of how localization can affect application logic, especially when translated text is also used as a database key.
What happened?
The problem was reported in GitHub Issue #8605.
The affected configuration included:
- MMEX 1.9.4 64-bit
- Windows
- French interface language
- Creating a new database or opening another database
At first, the problem looked like a general application crash.
However, changing the interface language from French to English allowed database creation to proceed normally.
That provided an important clue.
The unexpected cause: two currencies had the same French name
MMEX includes a list of currencies when a new database is created.
Two of these currencies are:
- South Sudanese
- South Sudanese pound
In the French translation, both names had been translated as:
Livre soudanaise
That created a collision.
The two currencies are different records, but their translated names were identical.
The problem became especially serious because the currency name is used as a key when the initial currency data is inserted into the new database.
The result was effectively an attempt to insert the same key twice.
SQLite rejected the duplicate key, and the database initialization process did not handle that situation correctly.
Instead of reporting a normal database initialization error, MMEX ended up in a state where the application appeared to hang or crash.
Why did changing the language to English help?
The English names are different:
- South Sudanese
- South Sudanese pound
Therefore, the two records do not collide during database initialization.
Switching the interface language to English was consequently an immediate workaround.
Users affected by the problem could:
- Change MMEX’s interface language from French to English.
- Create the new database.
- Continue using MMEX normally.
- Switch back to French afterwards if desired.
This workaround was confirmed by the original reporter in Issue #8605.
Why was this more than a translation mistake?
At first glance, this looks like a simple localization error.
However, there was an additional problem: the translated currency name was being used as a key during database initialization.
A translation is intended for people and is not guaranteed to remain unique.
In this case:
- the English currency names were unique;
- the French translations were not;
- the database initialization code relied on those names being unique.
So a seemingly harmless translation change could cause a database initialization failure.
The important lesson is that localized display text can affect application logic when it is also used as a database key or lookup value.
The fix
The issue was addressed in two parts.
First, the affected French translation was corrected so that the two currencies have distinct names.
The translation for “South Sudanese pound” was changed to:
Livre sud-soudanaise
while “South Sudanese” remains:
Livre soudanaise
This removes the immediate collision in the French language data.
Second, the database initialization logic was improved so that this kind of duplicate-key condition no longer causes the entire database creation process to fail unexpectedly.
The relevant fix is tracked in GitHub Issue #8607.
The related database-generation code in sqlite2cpp.py was also updated as part of the fix.
What should users do?
If you are using a current MMEX release, simply use the latest available version.
If you are specifically affected by this problem in an older build, switching the interface language to English before creating the database is a practical workaround.
After the database has been created successfully, you can switch the interface language back.
As always, keep a backup of your MMEX database before performing major version changes or database migrations.
Summary
The MMEX 1.9.4 database-creation problem reported in #8605 was not caused by a corrupted database.
It was caused by two different currencies receiving the same French translation, combined with database initialization logic that expected those translated names to be unique.
The immediate workaround was to create the database using the English interface.
The fix corrected the conflicting French translation and improved the database initialization path so that this type of duplicate-key condition no longer causes the entire database creation process to fail unexpectedly.
The lesson is simple: translations are data too.
And when application logic depends on that data, a localization bug can become a database initialization bug.