if keyboard_check(ord("H"))
{
var cc = 0;
repeat(35000) {cc = choose(0,1); if cc {count += 1;}}
}
#macro lang global.language
global.language = {
menu : {
play : oyna,
exit : çıkış
},
level_1 : {
do_this : Git felan filan
}
}
draw_text(x,y,lang.menu.play);
JSON files don't play well with source control, unlike INI files. There are places where INI files are overused, but I recommend either creating your own text format for localization (plurals are particularly difficult) or using INIs for their simplicity. For example, Czech uses a different plural for 2-4 than for other numbers. Here's a more professional look at localization (from the developers of one of my favorite games): https://factorio.com/blog/post/fff-244There's zero need to use ini files. I would highly recommend against using inis for basically anything. JSON is much more suited for this purpose. You create your JSON file, populate with languages, and populate that with string. You can load JSON into a struct no-fuss through GML and everything is preserved, so no need to mess around with inis.
How does JSON plays any worse than INI with source control? I've had zero issues myself. It's set up almost identically to actual code, so I just don't see how. INIs are fine for games with a small amount of text, but with larger games like RPGs and adventure games, the amount of text gets to be unmanageable unless you can organize it to a far greater degree than INIs allow. Creating your own format is fine, but it's likely to look a lot like JSON after you're done if you're doing something with a lot of text, and since GM has built-in (optimized) functions for JSON...JSON files don't play well with source control, unlike INI files. There are places where INI files are overused, but I recommend either creating your own text format for localization (plurals are particularly difficult) or using INIs for their simplicity. For example, Czech uses a different plural for 2-4 than for other numbers. Here's a more professional look at localization (from the developers of one of my favorite games): https://factorio.com/blog/post/fff-244
Specials meaning like codes for text colors, effects, etc.? Wouldn't that be in the text itself and thus won't matter where you're getting text since it'll all be a string at the end?I'm thinking if my texts were not parsed with specials and references, some JSON stuff would probably work fine, but in this case maybe a dirty switch is the way to go.
Either way, I'll leave it unsolved and see if someone has a better solution for my situation.
I've always used some kind of a tag system. Commands are parsed and replaced in-game with the necessary code on-the-fly.Right, the specials are just dotted in the dialogues and such to trigger events, player choice conditionals, play a sound effect etc.
But as you can see in my example above (the second picture) string(sound_effect) wouldnt execute properly if it was read from a file... Right? Now I'm unsure
I think the string would end up containing "string(sound_effect)" and not "X"
draw_text(x, y, "Hello! How are you, " + player_name + "?";
It's a bit of work up-front, but it makes working on dialogue so much faster that I couldn't imagine doing it otherwise now. It saves so much headache.Hello! How are you, [player_name]?
It's just a string. It's parsed in-game. What I do is:If tags are something in GM ive never used them. Can you explain what [player_name] is?
string_pos(_string, "[")
string_pos(_string, "]")
For short snippet translation, using JSON isn't exactly a great idea. For example, for English, the word "minute" has two variants: singular and plural. For other languages (like Czech), there can be more than two variants. The devs of Factorio ran into this problem.Creating your own format is fine, but it's likely to look a lot like JSON after you're done if you're doing something with a lot of text, and since GM has built-in (optimized) functions for JSON...
minute1=minute
minute2-4=minutes
minute5+=minutes
minute1=minuta
minute2-4=minuty
minute5+=minut
minutes=__1__ __plural_for_parameter_1__[1]__minut__[ends in 01-19]__minute__[rest]__de minute__
Because there's no trailing comma at the end of objects or arrays, any commit adding data to the end of an object or array has a chance of getting a merge conflict with another commit adding data to the end of an object or array. In comparison, INI doesn't have comma delineation. So, if you add data to the end of a section (and for localization, there's probably only one section per language, or maybe one section per file), there is no chance of any merge conflict.How does JSON plays any worse than INI with source control? I've had zero issues myself. It's set up almost identically to actual code, so I just don't see how. INIs are fine for games with a small amount of text, but with larger games like RPGs and adventure games, the amount of text gets to be unmanageable unless you can organize it to a far greater degree than INIs allow. Creating your own format is fine, but it's likely to look a lot like JSON after you're done if you're doing something with a lot of text, and since GM has built-in (optimized) functions for JSON...
1. {
2. "list": [
3. "a"
4. ]
5. }
1. 1. {
2. - "a": "A"
+ 2. "a": "A",
+ 3. "b": "B"
3. 4. }
1. 1. {
2. - "a": "A"
+ 2. "a": "A",
+ 3. "c": "C"
3. 4. }
1. 1. {
<<<<<<< Branch A
2. - "a": "A"
+ 2. "a": "A",
+ 3. "b": "B"
=======
2. - "a": "A"
+ 2. "a": "A",
+ 3. "c": "C"
>>>>>>> Branch B
4. 5. ]
5. 6. }
[Example]
1. a=A
1. 1. a=A
+ 2. b=B
1. 1. a=A
+ 2. c=C
1. 1. a=A
+ 2. b=B
+ 3. c=C
git commit
regularly, then as long as the Git repository stays intact, I can mess up my codebase as much as I like without any permanent repercussions. After all, if I break anything, I can always roll back to the last good commit. The third, if minor, reason is that it saves so much space in comparison with backing up the whole project multiple times (though since computers have so much memory, that's much less important nowadays).Yes, I read that article. That method of localization/translation is only feasible for projects with a minimal amount of text. You're not translating individual words in an RPG/Adventure game; you're translating a novel's worth of dialogue.For short snippet translation, using JSON isn't exactly a great idea. For example, for English, the word "minute" has two variants: singular and plural. For other languages (like Czech), there can be more than two variants. The devs of Factorio ran into this problem.
An old localization file for English used to have these lines:
But for Czech, had these lines:Code:minute1=minute minute2-4=minutes minute5+=minutes
Notice that the Czech translation has a different plural for 2-4 than for 5.Code:minute1=minuta minute2-4=minuty minute5+=minut
There are many plural localization rules. The devs of Factorio found it easier to create their own format for snippet translation. This is what they ended up with for Romanian:
Code:minutes=__1__ __plural_for_parameter_1__[1]__minut__[ends in 01-19]__minute__[rest]__de minute__
That's human error, not a fault of JSON. If you're consistently having that issue, you need to be more careful in making your commits. Alternatively, you can take a page from Haskell and place the trailing commas at the start of the next line:Because there's no trailing comma at the end of objects or arrays, any commit adding data to the end of an object or array has a chance of getting a merge conflict with another commit adding data to the end of an object or array. In comparison, INI doesn't have comma delineation. So, if you add data to the end of a section (and for localization, there's probably only one section per language, or maybe one section per file), there is no chance of any merge conflict.
Sure, INI is less powerful than JSON. But, in my eyes, that's a plus. When programming, it's usually a good idea to use the least powerful tool that can accomplish the task at hand.
{
"name": "John"
, "age": 21
, "job": "Mechanic"
}