With my game, I started localization relatively late and it was a pain to implement it, so the sooner you start the better. Also it helps to know which languages you want to support. Especially Chinese can be problematic both in terms of file encoding because of font licensing; or Arabic as it's right-to-left. The way that worked for my game was having a JSON decode to ds_map, so when you switch languages, the ds_map called "string_map" would get filled with the language in question. In hindsight I would also suggest doing your own parsing on top if you're using variables in strings.
For example take the string "You scored 123 points!" where 123 is filled by a variable. I "solved" this by having two entries that I concatenate like "You scored" + score_variable + "points!". But that's bad because this doesn't work for all languages and your translator(s) will have a hard time trying to make it work. So better have something like "You scored {x} points!" and write a script that replaces a token with a variable.
Also watch out for text lengths, for example German is notorious for very long words. it's better to detect possible overflow and have the text scale down than to just cut it off at the risk of vital information not showing to the player. My rule of thumb is that German is around 1.5 to 1.75 times longer than any given English sentence.
Finally, give your translators as much context as possible, they need everything they can get. Especially with spoken dialog it's important to know who is speaking to whom as well as the social standing and gender of the speakers. When you use a lot of individual words, "cancel", "go", "miss", context is also important. E.g. "go" can have so many different meanings: In an adventure it means "walk over to", on a text box it could mean "okay, confirm and close", when a referee says it at the start of a round it means "the game is on for everyone," etc.
Hope that helps!