Multilanguage support

[freemius]

Multilanguage support

[vovafeldman]

Thanks @Mte90! We'll check this approach and try to add it in 1.2.0.

[danieliser]

Based on recent discoveries in how translate.wordpress.org works, this won't make any difference. The freemius strings at this point get auto loaded in with all other strings for the plugin.

IE A plugin with 30 strings and freemius will show ~330 strings in the list at translate.wordpress.org/plugins/plugin-name.

Trying to get the meta-i18n team to address it, slow goings convincing them its an issue at all.

[vovafeldman]

Due to @danieliser recent finding, we are still trying to figure out what are the best practices for localizing the SDK correctly.

[danieliser]

@vovafeldman Still trying to convince them one member at a time. Get a few more people in the #meta-i18n channel talking about it could help :)

[Mte90]

Well alert us when you start to talk about this on slack #meta-18n so we can leave our feedbacks

[danieliser]

@Mte90 If your already on wordpress.slack.com jump into the meta-i18n channel. I have just been jumping in every few days bringing it up again once I see its not the latest conversation ;)

Best bet though is for others to go in and start the conversation for themselves (IE Complain on your own behalf).

If every freemius dev does this, as well as any other plugin/theme dev that bundles any library that includes translatable strings then we can hopefully make them realize its a bigger issue than they prefer to acknowledge.

Another issue that I determined you can point out is usage of Core WP strings in your plugin. I published a plugin last week which uses a modifed Admin Nav Menu Walker class. I copied it directly from core, added one hook so that we can customize easily. Didn't add strings or change any either. So now all of the __( 'string' ) that are loaded in the core langpacks are now being forced upon my translators. Despite the fact that those translations will never be used. Even if my translators translate them, they will still be loaded from core's langpack.

So check your plugins & translation string counts, and find any excuse to go nag them about it.

My final recommendation to them was this: If a string in freemius is translated in my plugin to Italian for instance, then every other plugin that includes that exact string (matching string, context & text domain) should be auto filled based on that translation. This would mean translate it once for each language and no need to do it again for the next plugin.

[Mte90]

I know the problem that glotpress reconize all the string and ignore the textdomain and is a problem also of poedit.
They suggest to not use the wordpress terms but yours because you don't know if they change in the future but I am agree that sometimes the terms to translate are very common like Nexṫ.

[danieliser]

@Mte90 That may be true about glotpress by default, but with minimal modifications it can check text domains.

I don't believe though that they use any typical GP functionality. IE GP by default requires you to upload a POT file. Since my POT files do not include those extra strings they are obviously using a custom scanning tool.

Likely NPM based custom tool since that is the best way now adays to passively scan files.

If thats the case even if they don't use an NPM package all modern scanners are completely capable of detecting textdomains and pulling strings accordingly.

Check out the npm package "wp-pot".

My point being if I can make it work on my end, they can do it globally too. Just a choice they refuse to make.

Even a php scanning tool can be modified to store the textdomain and then filter out non matching TDs.

PS I have GlotPress installed locally, both the WP plugin version & the standalone, neither offers automated scanning, all require uploading a POT file, so they obviously have a custom scanning tool.

[Mte90]

Yeah I think too that it's easy to adapt and use the textdomain specified from the plugin ignore all the rest.
Sure, I am a PTE and I can confirm that they scan all the code in search for the gettext functions.

[danieliser]

@Mte90 Perfect, since they obviously have a custom scanner, storing text domain, context & translator comments per string would be simple enough. If they did that they could even generate a unique hash for each string. With that hash you could compare strings across plugins/themes super easily. And if you translate that hashed string for one plugin/theme, auto fill it for others.

IE

sha1( array( 'string', 'context', 'text-domain', 'comment' ) );

Simple concept, easy to manage, never have to worry about duplicate work ever again etc.

With a setup like that translations for the repo could be community driven even more. IE translating for one plugin could mean you helped translate 50 others.

[vovafeldman]

@danieliser how about writing a guest post on Freemius "Dear Meta team: help us making WordPress.org localization friendly when using Frameworks"? I can help out spreading the word and making sure it's covered by the big WP news sites. What do you say?

[danieliser]

@vovafeldman I can do that. I need to get my thoughts on the matter down anyways. I can see this being a huge thorn in my side over the coming months as we release half a dozen small plugins.

[intoxstudio]

I have run into the same issue, now that I want to make use of automatic translation updates. The polyglots team is unfortunately not responsive on the matter, and the FAQ states that it's not necessary to use several textdomains (for performance reasons).

I definitely think a blog post/petition is the best way to get the word through.

[seezee]

+1 on this.