L10n

[Deledrius]

These changes re-enable the console command App.SetLanguage, allowing it to be set in an ini file. To make sure it's set early enough and to allow for future options being set via ini, I've added an optional general.ini for general settings to be read in before the login dialog is shown.

Also included is a fix for a crash that would occur when visiting Eder Tsogal using any language other than English due to an attempt to translate the name of a Scene Object in Tsogal with no name.

I've also removed the code which read from Windows' registry entry for the Uru uninstaller to determine a default language, as this is no longer necessary and is not cross-platform.

[diafero]

Why is a global ini file necessary for the language configuration - shouldn't this be part of the ini files read from "Application Data/Uru Live"?

[Deledrius]

That's precisely where it goes.

I added a new one because the existing ones are specifically marked for audio or graphics. The discussion in IRC concluded that we may want to use additional global settings in the future, and this general.ini will allow that.

[diafero]

I see... I guess I was confused because plClient runs all ini files from the Init directory, without any hard-coded names. But this one naturally has to be loaded earlier.

[Hoikas]

Before this is merged, I'd like to be certain that none of the already existing code will not save localized strings to the vault. I seem to recall that someone (Paradox?) found some in the MOULa vault from someone enabling localization in their client.

[dpogue]

Since the consensus here seems to be that we want more review before merging this to master, could we at least pull it into a branch of H-uru/Plasma so that it gets a bit more visibility and more experienced users could test enabling it?

[Deledrius]

I don't have time to do any work on it myself right now. Do I need to re-initiate a pull request into a new branch, or can that be done from this request?

[dpogue]

That can be done from here (or rather, from the command-line).

[Deledrius]

That's what I thought, but I just wanted to be sure. :)

[dpogue]

Okay, now I'm a bit conflicted about this one after the discussion on IRC yesterday about the Vault nodes:

[Deledrius] I did find the non-english strings in the vault, but I didn't narrow down what's writing it there yet. It's the AgeName in String64_1
[Deledrius] the image caption default is there, too, but that seems like that should be fine to be stored that way.
[Paradox] hmm, was the AgeName one in the Journals folder?
[Paradox] It might be the folders that the KI creates for storing images/notes

I think it's fairly likely that these are coming from the Python rather than from this code, but that Python doesn't cause problems unless this is enabled.
We definitely don't want this merged to master as long as it has potential to cause Vault weirdness.
On the other hand, I hate leaving this sitting here for months while we make potentially incompatible changes to master. :(

[Deledrius]

Technically, these particular changes affect nothing as long as the client isn't set to another language; it still defaults to English. It would make it trivially easy for people to pollute the vault, however, as long as the cause in the Python isn't tracked down and fixed, but that's a separate issue.

[branan]

Has any progress been made on figuring out how internationalization interacts with the vault? This would be pretty cool to be able to enable, and it's a highly visible feature for users.

[dpogue]

Age names in the vault are translated because they use the same function that the KI uses for displaying them, which runs them through the xLocalization code.

Ideally the names should be localized when they are read from the Vault, rather than storing them in localized form.

[Deledrius]

The python fixes available now should address the concerns here. I believe it's ready for wider testing, if possible.