Localisations for ExplorerPatcher

[Galixte]

Hi,

I suggest this topic to list all the ExplorerPatcher translations:

• French: Localization #175 (comment)
• Korean: Localisations for ExplorerPatcher #363 (comment)
• Russian: Localization #175 (comment)

To translate the “settings.reg” file from ExplorerPatcher to your language take a look here: #175 (comment) and don’t forget to share here the link to your translation.

[valinet]

Only BIG caveat is these have to be kept in sync with the upstream. I don't know if the links you provided have files updated for the latest build, for example. The "Properties" interface is constructed based on that file - if you do not have a translation for a particular option, then that option won't be shown at all. Not to mention, there could be the rare case where some setting has changed meaning in a new version. So what can I say, I don't particularly like this idea. People do this, then something breaks and they blame the app, disregarding this modification they made, and then they come and blame me. So, how should I respond? Not to mention it is hard to diagnose and pinpoint to this being the culprit.

Not to mention, I honestly do not understand the need for this - you need to deal with English when downloading this anyway, and then that interface you see it only initially when configuring, then it is just there, in the backend, not bothering you. Things that have to be localized, like menu entries etc, I absolutely strive to label using localized strings from Windows - indeed, I'd considered an untranslated Win+X menu not acceptable, for example, but translating and maintaining a translated settings UI itself is too much work for this kind of project, and very very unnecessary in my opinion. Again, if it were something that sat on your screen everyday, I'd understand, but it's not, so yeah... I don't get this need.

So, in its current form, I advise against this. And I don't want to change the implementation necessarily, because I like it technically and it is very easy to maintain. Still, even with a different implementation, maintaining translations would also be extremely time consuming, so it's simply something I don't want to bother with, as I consider it very unnecessary. Maybe when the app's functionality will become more stable, if ever, maybe then, although still, I don't fancy it...

Or providing a translation server maybe... I don't know, solutions too complicated for a problem that's not even there, imo...

[BraINstinct0]

Anyways, I've done it too: (may not be complete)

• Updated for version 22000.318.375
• Updated for version 22000.318.38.2

• Korean

At least noting which version this l10n is for would be (possibly) less confusing.
Though, this shouldn't be considered official!

[gailium119]

maybe you can make a dxgi.dll.mui file and drop it into C:\Windows\xx-xx

[BraINstinct0]

Yes I bet that is possible. But, (and here comes the big BUT) clearly this project is already quite demanding for @valinet being the one and only dev. I don't think we'll be able to get timely updates(considering beta&dev release is updated quite often these days), if we put additional workload upon him.
So if there's a way to do it as an 'addon'(separate from valinet's repo), I'd def say that's a good idea. But before someone does that(i.e. maintain all those translations) I don't see multilanguage support as feasible.

[valinet]

Pretty much what @BraINstinct0 said, laid out in nicer terms my exact thoughts on this. Languages are too much hassle, takes too much work and needs input from too many people, and is something that does not improve anything regarding the original purpose of this project at all. Like, I like to think I am not the obtuse one here, as I have implemented a couple of side features as well, like the settings GUI (which that is not also core to the functionality of the patcher), recently the setup/update mechanism, as I understand and have a marginal use of them myself as well. Plus, it at least adds some value to the project. But localization adds no value in my opinion. What if the UI is not translated? How many times a day do you see that? You anyway need to know English to get there in the first place. The words in there are incredibly basic, it's simple English, so it's not hard to understand using Google Translate either. Plus, one can enable/disable stuff and see what it does. I agree, it's nice to have, but it's too much burden, simply put. And yeah, it's unmaintainable in my opinion as well. Even disregarding the current limitations regarding how the strings are delivered (which I could literally waste the hours to fix, instead of working on something else more useful, like new functionality, but I could make a working system out of those as well, it's not about lack of knowledge), let's say we have a system for translations in place. I make an update, now everyone has to get on board and do their job before I can release it. Or instead, release as is and then issue updates once very translator localizes that one string that changed. So, 20 updates a day or so... Or no, instead, make channels, like release preview, stable, staging etc... Like, yeah, doable, but very hard to maintain as a single person. I don't know if you have any idea how much of my time this project eats already, and I am not saying that in a bad way, as I enjoy the learning part, that more than compensates for any amount of time spent, but translations are something boring that take a lot of infrastructure and time to do right and teach me nothing. So, why should I spent time with that, considering it also does not bring anything useful to the goal of the project...? And it doesn't add much value for you either, if you sit down and think about it... Also, again, I have a workplace as well, I cannot spend all the time working on this.

Regarding this translation files floating around, yeah, it's a free world, I like living in freedom, I have nothing against them, in the current implementation, the problem comes when someone grabs that, uses it in v1, then v2 comes in and he/she does not see the new settings, or even other things break. Then, issues start flooding even more than they usually do. Also, no one mentions they use a language file, because it does not seem important. I mean, few people mention what's relevant in an issue request at all anyway. So, good luck debugging that.

So yeah, again, I don't see the upstream supporting this any time soon, if ever. My recommendation is to simply skip this one, or, if absolutely necessary for whatever reason, fork this project and provide a localized version if you want. That way, people can report issues there, and only the relevant ones should be directed to the upstream.

Thanks

[BraINstinct0]

A short summary for other to-be translators:

Fork this project and provide a localized version if you want. That way, people can report issues there, and only the relevant ones should be directed to the upstream.

Fork, edit, build, and maintain a separate Issue tracker (or a simple Github Issues tab).
Let the problems of translated versions stay where they should.

[zetaloop]

Here is the Chinese Simplified translation.
Version: 22000.493.42.9
Not fully completed (due to some encoding problems of the notifications).
Update when I'm free.