Allowing modders to create language packs

Does anyone have a good solution to allow the creation of language packs by people who don’t have the source code? I’m using a .resx file as the documentation advises, but every time I try compiling it into a .resource.dll file using anything other than Visual Studio, the program falls back to the default language. I can get them to work if I add them in the IDE, but that defeats the whole purpose of this exercise.

These are the commands I’m using to compile the resx file:

“C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\ResGen.exe” Localization.resx
“C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\al.exe” /t:lib /embed:Localization.resources /culture:en-DE /out:MyGame.resources.dll

You could roll your own i guess. I did one in my day job so could replace words that were in the resource files, while keeping the data in the resource files for other users. It uses a DB back end but that coukd be swapped out for text files.

If i get chance ill see if i can do a version for MonoGame.

You will need to keep in mind though in MonoGame, Sprite fonts will need to be set up to cater for the multi cultural characters or it will throw an exception.

Not done it my self, so would be interesting to know what those settings would be in the SpriteFont.

Compiling strings into dlls sounds like a garbage approach. Don’t do that. Instead, simply set up md or csv files with key-value dictionaries of your locales - each in its own language folder.

1 Like

Indeed, SpriteFont and LocalizedSpriteFont won’t work in this scenario, so I suspect I’ll be replacing SpriteFont with FontStashSharp.

The more I look into this the more it looks like I will probably need to dump the resx files and redo the whoooole localization process… [thousand yard stare]…

I do want to keep the localization library strongly typed, though. Intellisense and compile time errors are just too good to pass up.

Someone in my PM’s reminded me that XMLSerializers exist, so maybe that’s the way to go. Write a Localization class with all the same strings, use “serialize” to create the ‘template’ language pack file, and then load other language packs at runtime with a simple “deserialize”.

Except… that won’t work with a static class. Okay, might need to do something a bit hacky here. Or pinch some code off of stack overflow.

I did it by deriving from the intrinsic C# classes. You can then still use the resource files for base value and intercept if there is a value in the user language file for that culture.

Would recomend using JSON over XML, but thats my preference.

I just set a framework for localization for my games
my solution is pretty simple
1- Fonts → Fontstashsharp
2-Text → xml file in plain text, simple to manage, it has 3 fields, language code, string code and localized text
for example in plain text it is like this : en , [GameTitle] , My game title here
add your xml attrributes as you want to name them
3-create a simple xml loader for your game, so anyone can add new languages , the only thing they need to know is the language code + string code, so they can translate any text

I could have made the language code as a file so I can have multiple files instead, that’s another option if you want. But for now, I have all languages into one file, and I edit all of them in excel and with one button export all into xml.

4- In my game I have a dictionary with all the language and string codes as keys to get the text

I tend to use more like a simple textfile, with code=text in each line. (1 file per language). A parser is written in minutes. It’s fast, small, scales well and doesnt need any sort of character masking (except newline)

So I can just send the original file to a translater and he can just translate without knowing anything about file format. And it satisfies my obsession for packing everything :smiley:

Thanks for the advice, everyone. I’m currently using JSON, but I might end up just flatpacking it. I really was overthinking this something horrible.

I have a new problem, though. I’m using Monogame 3.8.1 and getting this exception from FontStashSharp (installed with Nuget):

System.IO.FileLoadException: ‘Could not load file or assembly ‘MonoGame.Framework, Version=3.7.1.189, Culture=neutral, PublicKeyToken=null’. The located assembly’s manifest definition does not match the assembly reference. (0x80131040)’

I… kind of just assumed it would be up to date. Is it not?

(Edit) Managed to get it working by downloading the source code, changing the compiler target to .Net Core, and pointing it at my local copy of the Monogame source. I shall happily move forward with that and continue to subconsciously hate NuGet. I know that all the time’s it has wronged me were probably my fault somehow, but all the logic in the world won’t stop my lizard brain from hoping it withers and dies horribly.

1 Like

Yes, I did the same with FontStash as you did, since it was referencing an old monogame version.

That’s really weird.
I’ve made a small sample that uses latest nuget versions of MG & FSS and it works fine: GitHub - rds1983/FontStashSharpTest

cc: @Quasar, @MysticRiverGames

1 Like