PlugIn Translation possible?

[Frontcannon]

This is a question that came up while working with .pdn a few minutes ago. I noticed that I had several menues twice, in German and English (for example: 'Distort' and 'Verzerren').

Though that problem is likely to be the author's fault (pyrochild's PlugIns are all in the right -German- sub-menues), I'd love to see some of the more complicated PlugIns (best case: every PlugIn) to be able to be used in different languages.

I think that's possible, but I have no idea whatsoever if that idea would impose a whole lot more work on the PlugIn authors or if applying some simple modifications to the source code would already do the trick.

So some thoughts on this from experienced translators (Zagna comes to my mind) or PlugIn authors would be appreciated.

Edit: I mainly refer to the UI!

Edited May 1, 2010 by Frontcannon

[Simon Brown]

If the submenu the plugin uses is one of the ones that effects included in Paint.NET use, they can have it use the correct one with the SubmenuNames class.

[Frontcannon]

So you do have to have the ability to code if you want to, say, translate the UI of Smudge (implying you have the source code)?

[Simon Brown]

I was talking about using the correct submenus.

As for the UI, it'd be possible by editing the source, but I don't think there's an easy way to find out which language Paint.NET is set to use (without doing something hacky like guessing by reading which translation is provided by SubmenuNames). Obviously you'd also need someone to provide translations.

[Frontcannon]

Having a PlugIn which knows what translation pdn is using would be excellent, I haven't even considered that.

I imagined it this way:

The PlugIn author releases a PlugIn.

It then is either

1. directly translated by a translator who edits the source which is provided from the author (less work for the author)

2. indirectly translated, meaning the translator makes a table of what translates to what and the author edits his PlugIn (more work for the author)

The process is completed by the author releasing the PlugIn in either language (SmudgeEnglish and SmudgeGerman, for example).

[Zagna]

*blush* :red: me, an experienced translator?   :red:

From my point of view, it would be best for something like this:

• Plugin authors would use the internal localization in some way, such as when setting the dialog texts, use whatever method is used to get a string from PdN and supply the method with a default string if the string isn't found in Strings.xx.resources.

• That way even if the xml entries don't exist in the resources it would use the default english that's in the code?
• Then the plugin author would list a set of strings in a <code> bit at the end of the topic posting the plugin. Stuff like Madjik.Effect1.VarA or BoltBait.EffectC.VarX and so on.
• Then I could just copy paste the xml into my own Strings.xx.resx and translate there.

The plugin author would just have to use the internal resource manager and all the translators are left to choose which plugins to translate.

Having to work with the plugin author to translate and creating multiple versions sounds insane and prone to errors and any changes to translations would create a logistics nightmare.

Leaving the translation to me and my own Strings.xx.resx is in my opinion the best solution. 

Edited May 2, 2010 by Zagna

[Frontcannon]

The former ideas were designed without the idea of the PlugIn knowing what language is used

If Simon's suggestion is successful, we can deal with it your way.

[Simon Brown]

If Simon's suggestion is successful, we can deal with it your way.

Well, Rick has posted a way that plugins can detect what language is used. However, they can't access Paint.NET's translations and I can understand why Rick probably doesn't want that.

[Frontcannon]

So, as I have (hopefully) understood it, the PlugIns would still have to be translated directly? They know what language they're supposed to use, but you can't have the PlugIn translation in pdn's strings.recources...

From the 'PlugIn Rules':

Plugins should not use the PdnResources or PdnInfo classes.

The text and images that Paint.NET uses for its own user interface are not for plugins. Strings are not guaranteed to have the same text between versions, or to even exist. Same with images. If you want to take advantage of the localized text for effect submenus such as Artistic, Blurs, Distort, etc. then please use the static SubmenuNames class.

Edited May 2, 2010 by Frontcannon

[BoltBait]

If you pick one of the standard English submenu names in CodeLab, it will handle this for you.

[Rick Brewster]

So, as I have (hopefully) understood it, the PlugIns would still have to be translated directly?

How else would they be translated? Magically? I'm not sure what else you're looking for here.

[Toli]

As for the UI, it'd be possible by editing the source, but I don't think there's an easy way to find out which language Paint.NET is set to use (without doing something hacky like guessing by reading which translation is provided by SubmenuNames). Obviously you'd also need someone to provide translations.

string language = Thread.CurrentThread.CurrentUICulture.TwoLetterISOLanguageName.ToLowerInvariant();

[Frontcannon]

How else would they be translated? Magically? I'm not sure what else you're looking for here.

I meant it in a way that the PlugIns would have to be be usable in different versions for different languages instead of havng like a PlugIn-string which comes with pdn.

Maybe I'm on the completely wrong way here.