language stuff

[t0stiman]

• added ability to translate station names
• fixed "Failed to find locale language" warning (it reported the wrong language)
• added more languages and credited the translators

Fixes #107

(This is a reopening of #108)

[Insprill]

How are map-specific locales supposed to be created? I don't see anything changed on the editor side.

Create locale.csv in the same folder as info,json of the map. For example:
locale.csv

You aren't supposed to ever create the zip manually though, when you build the map from the editor that should be the zip you distribute. There needs to be good editor tooling for creating localizations.

How much work would be involved with switching to the localization library most other mods now use? I think that would be a better route than continuing to reinvent the wheel, assuming it covers all our needs.

(this discussion was originally in a comment on #108)

[t0stiman]

There needs to be good editor tooling for creating localizations.

Yes, that would be ideal. However, that would take more effort to make then I am currently willing to invest in this feature.

[Insprill]

How about switching to Language Helper? I haven't worked with it before, so I'm unsure how much work would be involved. If we do that, map creators could then just provide a link to a Google sheet in MapInfo, and we wouldn't have to worry about custom tooling or maintaining our own language implementation.

[t0stiman]

Now it uses language helper. Not just for the map-specific translations but also just Mapify.

Specifiying translations works like the cargo in and outputs:

[t0stiman]

Fun fact: I was wondering why the you made CargoSetMonoBehaviour... And then I had to do the same xD

[WhistleWiz]

Using a MonoBehaviour for this is unnecessary. You can serialize to a string in either XML or JSON and deserialize after importing:
https://github.com/derail-valley-modding/custom-car-loader/blob/ea44c611a6e03160aa62e5e6b4b54d73d8942719/CCL.Types/Components/ShaderGrabber.cs#L33

[t0stiman]

Using a MonoBehaviour for this is unnecessary. You can serialize to a string in either XML or JSON and deserialize after importing:

Eh, but then we'd have to add the JSONObject library. I'd rather keep it as it is for now, it just works™

[WhistleWiz]

You don't need to, you can use the built-in XML serializer, or reference the same package DV already includes (JSONObject is just a wrapper over those for utility I believe).

[Insprill]

The MonoBehaviour hack is good when you need references to GameObjects or assets, but since this is simple data, it's easier/more reliable to use Wiz's approach.

We already do the json thing for streaming scenes using Unity's JsonUtility.

dv-mapify/MapifyEditor/Streaming/SceneSplitData.cs

Lines 5 to 16 in d1f7d45

	[Serializable]
	public class SceneSplitData
	{
	public string[] names;
	public int xSize;
	public int ySize;
	public int zSize;
	// Not sure *exactly* what these do but this is what DV sets them to ¯\_(ツ)_/¯
	public int xLimitsy = 15;
	public int zLimitsy = 15;
	}

dv-mapify/MapifyEditor/Export/BuildUpdaters/Streaming/StreamingUpdater.cs

Lines 12 to 13 in d1f7d45

	SceneSplitData splitData = SceneSplitter.SplitScene(scenes.streamingScene, Scenes.STREAMING_DIR, mapInfo);
	mapInfo.sceneSplitData = JsonUtility.ToJson(splitData);

dv-mapify/Mapify/Map/MapLifeCycle.cs

Lines 266 to 267 in d1f7d45

	SceneCollection collection = streamerObj.AddComponent<SceneCollection>();
	JsonUtility.FromJsonOverwrite(mapInfo.sceneSplitData, collection);

[Insprill]

It'd be nice to get this merged soon; the only thing blocking is the MonoBehaviour vs JSON thing. I'm more in favor of switching to JSON. Are there any arguments against it, or anything in particular blocking this?

[t0stiman]

I tried to implement the JSON method, but it didn't work. I could give it another go some time

[t0stiman]

This branch is borked by build 99.7, needs fixing