I18n issues

In order for the translation platform to correctly import all strings in a plugin, the textdomain MUST be the same as the plugin slug.

Of course you may still continue to handle your own translations inside your own plugin.

The good side of enabling translation via translate.www.ads-software.com are:
– The style and quality of translations will be maintained by the same people, who translated WordPress core.
– You don′t need to distribute updates to your code whenever there′s a small change in one of the translation files. Language packs will be generated and distributed automatically when at least 95% of the strings in the code have been validated.
– By deleting the translation files from your code your plugin will have a smaller footprint and quicker updates.
– And… it′s suggested standard way of doing it now

The downsides of enabling the standard translation platform:
– You get a bit less control (since you hand over the quality check to people who actually speak the language).
– Language packs are NOT generated if less than 95% of the strings in the code are translated.
– For some languages it may take some time before translations are validated (it′s all volunteer efforts). But if the quality is good, then virtually all language teams are happy to assign editor rights for your plugin to the people that already do your translations. (And then the turnaround time for fixing typos, etc., is down to minutes!)

• This reply was modified 6 years, 11 months ago by tobifjellner (Tor-Bjorn “Tobi” Fjellner). Reason: corrected translation domain to textdomain

Ok, but the strings in the dev version are imported automatically?

I don’t remember uploading them, so I’m figuring the automatic gettext thing works. I even found some untranslated Swedish strings from featured added a few versions back.

So, as far as I can see, I don’t need to change the textdomain to anything since everything already works?

I don′t know the deeper details of the system, but I guess it would still be good to change the textdomain from threewp_broadcast to threewp-broadcast. Search&replace should be relatively straightforward if you include the quotation marks around the string?

And I′m also surprised that Stable doesn′t import to the translation platform. Perhaps the small difference in textdomain is the issue at hand.

“Perhaps” makes me uncomfortable. :/

Is there nowhere to test one’s changes to the code before upload it to the repo? I’d love a staging repo where I can see what changes are made before uploading live.

Right now it feels like changing the textdomain (from something that obviously works) to something else because some unofficial WordPress blog says so, is very risky.

Are you referring to wp-info?
That site and that tool were developed by @casiepa who is one of the global mentors in the WordPress translator community.
When I look at the structure of your code, it seems to me that you′re marking stable the right way: trunk/readme.txt has a stable tag that points to an existing subdirectory under tags…
In this case, /trunk would be used for the “Dev” project, where you can experiment, add new strings before releasing a new version, etc.

I guess if you update /trunk, and perhaps even tag a new version, but don′t mark it as stable, then you should be able to download these packages from the Advanced tab so that you could test-drive it.

Hi Edward,

Concerning the text domain, this is the official text: https://developer.www.ads-software.com/plugins/internationalization/how-to-internationalize-your-plugin/#text-domains

If you need more info, let me know!

Pascal.

All right. So now that we’ve figured out that the stable tag is correctly set, then I’ll search and replace for ‘threewp_broadcast’ and replace it with threewp-broadcast? Then upload to the repo and that won’t kill anything?

That should work. Upload to trunk and don′t change the stable tag, should give you possibility to download a dev-version and check it out.

Uploaded as revision 1856674.
Didn’t change the stable tag.
Removed the text domain from the plugin header.

I dare ask whether it works…

Why ‘removed’ ?

Your https://plugins.svn.www.ads-software.com/threewp-broadcast/trunk/ThreeWP_Broadcast.php should have a Text Domain and it should be the same as your plugin slug, so:
Text Domain: threewp-broadcast

But from a (very very) quick glance, the rest looks globally ok (I only opened 2 files!)

Removed because

After WordPress 4.6 came out, the Text Domain header is no longer required if it’s the same as the plugin slug. It’s now the default value.

So no longer necessary, according to the docs.

Anyways, I’m not releasing anything officially until you guys are happy with the translations.

And you are 200% right! As you have set Requires at least: 4.6 , the Text Domain is no longer needed.

I see that for e.g. FR the dev (so trunk) is working great: https://translate.www.ads-software.com/locale/fr/default/wp-plugins/threewp-broadcast

So from what I see you are good to go for moving trunk to a new stable. When you see that ‘Stable’ is active on https://translate.www.ads-software.com/projects/wp-plugins/threewp-broadcast, to help your translators, you could upload the 7 .po files you have into the different locales: Click in the stable column next to the language and scroll to the bottom of page and find ‘import’ translations. This will put the strings in ‘waiting/suggested’. Then follow https://make.www.ads-software.com/polyglots/handbook/frequently-asked-questions/#as-a-plugintheme-author-how-can-my-translators-get-validation-rights if the people that helped you translate are willing to become ‘validators’ in their language. If they are accepted, the language packs for your plugin will be automatically created.
Once the full process works for a language, you can remove it from your /lang folder.

I tried doing as you said and importing the various .po and .mo files into the stable language branches but … no go. It just said it didn’t find any translations. :/

get-validation-rights

Oh, they still haven’t fixed that complicated system yet? I find it very, very inconvenient, as a plugin author, that I have to ask permission to add specific people, who might just be doing a drive-by translation, as translators.

I see it as an extra step that ensures decent quality of the translations. If I was a plugin developer and someone provided me with a translation to a language I don′t know, then I would be happy that someone who speaks that language runs a quick check of the quality.
Obviously, since this is driven by voluntary efforts, this will take longer time than simply including the translation in your plugin. But in the long run, it should be a good thing and the extra delay is mainly in the beginning, until “your translators” get approved with editor status.
There′s automatic propagation of translations between Dev and Stable, so once translations are validated and visible under Dev, they will be automatically copied to Stable, too.