Looking for translators

[exelix11]

Multiple users requested the ability to localize this project in their own native languages.
I'm planning to implement this feature for the next release and as such i'm gathering people interested in translating this application.

I'm opening this before starting work on this feature to gather feedback on how many people are interested in providing translations and any suggestions before i take a fatally wrong design decision. If you are interested reply here with the language(s) you are willing to add support for.

I will be posting any updates directly here so if you are interested enable notifications for new posts so you can keep up with the discussion.

The way i'm planning to implement this right now is the following:

• Each language will have its own json file in the resources folder so translators can work on it without recompiling the application
• Translators will be able to include a custom font to support alphabets that are not included in the built-in open sans font
  • Only fonts with a permissive license will be allowed since they will be distributed as part of the release package
• Most of the GUI will be able to be translated, for ease of providing support or finding bugs, debug and internal error messages will remain in english. .NET exceptions such as connection errors are already translated by the operating system itself.

[sskyNS]

Good job bro! I can provide translation contributions in Simplified Chinese(zh-CN) and Traditional Chinese(zh-TW)~

[THZoria]

Very good idea, my team on discord would be ready to work for the French part ^^

[exelix11]

cc @spreedated who worked on translations in #253

[spreedated]

My fork is still up and running.
Technically you have some choices to provide localization. Via JSON is only one, another common is an INI File or XML, actually any Textfile will do.
I used the built-in Microsoft method of Globalization Namespace.

[exelix11]

Starting with 6.0 the new GUI also builds for mac, linux and android making Windows projects specific stuff like resx either unapplicable or a pain to use which is why i was proposing jsons. Android in particular is a very annoying platform to support properly.

Most notably we lose winforms magic font support that just works and have to manually manage fonts and character ranges. This is the reason why localization didn't make it into the 6.0 release.

[spreedated]

Indeed, I share your view on this one and I guess an XML style or JSON is the best practice approach for it.
I'm not aware of any preexisting libraries for JSON localization, but doing it on your own isn't that difficult.
I would go with a separate project to implement the localization logic, plus I'm not sure about the existing GUI design pattern, but an implementation on MVVM should be easy when the bindable and observable properties are used correctly.

However, I'm way too technical here, as for the translators, I could provide translation in German and Polish.

[exelix11]

As for design, we are constrained by the lowest common denominator for cross platform.
In particular on desktop I use AOT to build framework-less binaries (so no reflection) and on android the same to build as a dynamic library I can call from Java.

Essentially, the application is a console app with sdl and imgui, which is an immediate mode gui that runs in a loop, kinda like a game engine.

Such is the unfortunate state of cross platform user interfaces that are not a web browser.

[spreedated]

Depending on which platforms you aim for, MAUI (former XAMARIN) is also a good approach, it aims at MVVM which implies cross-platform compatibility by strict encapsulation. AOT is common all over the .NET framework anyways and native Java library is used in the android part of MAUI.

However, with your approach using SDL/OpenGL makes it somehow independent and more versatile, but also more work to do since you have to build the layout, pages, behaviors (which imgui helps alot with) etc. yourself, also the architecture of the application.

Tbh, I am not familiar with the latest state of the project and I just saw that you released 6.0 last week so I'll definitely give it a shot. Keep up the good work!

[exelix11]

Last time i tried MAUI it did not feel stable yet, i did considering trying UNO or Avalonia though. The main problem that made me pick SDL in the end is the video renderer.

Truns out there is no "batteries included" library that allows playing raw video data without a proper container so i had to manually use ffmpeg which produces a framebuffer for each frame decoded. SDL gives me the low level flexibility of making a double buffered GPU renderer that does not allocate memory for each frame, other WPF-like frameworks did not seem to support this in a cross-platform way at the time i looked into it.

[DarrenWarrenV]

pl-PL here if needed!

[exelix11]

I made some initial work in the translation-support branch. This is still experimental, do not start translating yet.

Translation files will look like this:

{
  "translationName": "English",
  "translationAuthor": "SysDVR",
  "systemLocale": [
    "en-us"
  ],
  "imGuiGlyphRange": "Default",  // optional
  "fontName": "OpenSans.ttf", // optional
  "mainGUI_ChannelLabel": "Select the streaming mode",
  "mainGUI_ChannelVideo": "Video only",
  "mainGUI_ChannelAudio": "Audio only",
  // etc...
}

Of particular interest are the imGuiGlyphRange and fontName fields. These can be used to add support for other alphabets. In particular the first field must be one of these values and the latter the name of a font file to be embedded in the resources folder.

The systemLocale array contains which system locales are covered by this file so on first launch sysdvr will already match the system language, users will still be able to change it from the settings.

To be included in SysDVR, fonts will have to be distributed under an open license, a good example is Google Noto which seems to implement most alphabets.

Any objections to this design ?

Once this is done i'll start to think about what to do with the on-console settings app since that does have some text as well, but uses a different architecture.

[DarrenWarrenV]

No objections and instant help if needed.

[spreedated]

I made some initial work in the translation-support branch. This is still experimental, do not start translating yet.

Translation files will look like this:

{
  "translationName": "English",
  "translationAuthor": "SysDVR",
  "systemLocale": [
    "en-us"
  ],
  "imGuiGlyphRange": "Default",  // optional
  "fontName": "OpenSans.ttf", // optional
  "mainGUI_ChannelLabel": "Select the streaming mode",
  "mainGUI_ChannelVideo": "Video only",
  "mainGUI_ChannelAudio": "Audio only",
  // etc...
}

Of particular interest are the imGuiGlyphRange and fontName fields. These can be used to add support for other alphabets. In particular the first field must be one of these values and the latter the name of a font file to be embedded in the resources folder.

The systemLocale array contains which system locales are covered by this file so on first launch sysdvr will already match the system language, users will still be able to change it from the settings.

To be included in SysDVR, fonts will have to be distributed under an open license, a good example is Google Noto which seems to implement most alphabets.

Any objections to this design ?

Once this is done i'll start to think about what to do with the on-console settings app since that does have some text as well, but uses a different architecture.

Just my two cents, but instead of using prefixes for the categories, we could use objects.

{
"localeInfo":
{
  "author": "SysDVR",
  "imGuiGlyphRange": "Default",  // optional
  "fontName": "OpenSans.ttf" // optional
},
"localization": 
 {
  "mainGui": 
                    {
                            "channelLabel": "Select the streaming mode",
                            "channelVideo": "Video only",
                            "channelAudio": "Audio only"
                    },
  "settings": 
                    {
                            "settings": "Settings",
                    }
//etc.
 }
}

Another thing about encapsulation comes to the locale array; imho it's better to have separate files for each locale and named it properly inside the locale folder like "en-US.json" "de-DE.json" etc. (filenaming by languagecode) so they can be identified this way.

[exelix11]

I figured one might want the same language file for multiple locales, on start the app will load all the jsons (deserializing only the metadat fields) and pick the matching locale.

As for encapsulation, I'll think about it, don't see any real advantage cause I can't use fancy techniques like dependency injection or auto mapping to pages. Meant the prefixes as context for translators cause I happened to do some software translating and the lack of context in string files reduces the overall quality if the translator is not paying attention.