1

There is a plugin:

  • In admin area it has about 300 various strings added via __('', 'my-textdomain'). Most of these are form labels, titles, etc.
  • On "frontend" (which end user sees), there just 15 strings added via the same __('', 'my-textdomain') method

Most website editors will want to translate "frontend" part. Admin area part is technical and most editors will understand english version.

  1. Is it worth having two plugin textdomains - one for admin area strings and another one for "frontend"?
  2. Does it break any guidelines (the plugin is public)?
  3. Will it improve/simplify translator experience?
  4. Is it worth in terms of performance?

Something like:

  • __('', 'my-textdomain--admin') for admin labels
  • __('', 'my-textdomain--frontend') for "frontend" labels
2

Is it worth having two plugin textdomains - one for admin area strings and another one for "frontend"?

In theory yes

Does it break any guidelines (the plugin is public)?

glotpress which drives the wordpress.org translation section is unlikely to ave any of it. For it you have to use only one text domain which is the same as the slug of the plugin IIRC. Poedit and other software which basically do a string match on things like __() are not going to detect the different text domains and generate different .pot/.po files for both of them. Most likely a translator which uses such a tool will get everything combined.

Will it improve/simplify translator experience?

No, it will make it harder

Is it worth in terms of performance?

Unlikely. Last time I checked 50% of wordpress users use english, and for them it just makes no difference. For the others, it just doesn't sound like a big enough difference (this depends on the language it is being translated to as the biggest issue is memory consuption, and for languages like german you are likely to consume more memory as string are usually longer), and people that actually care about performance will use page caching in any case.

Wordpress translation performance sucks, and did suck for years. Until there is a better infrastructure it is just pointless to fight the flow. What you can do, is to think again why do you need a translation for the front end in the first place. Can't you just let the user customize the relevant strings instead of sending him to figure out how to do plugin translations?

| improve this answer | |
0

I am also looking for a possibility as described above. My temporary solution is to work with the context:

Example:

_ex( 'Post', 'frontend', 'my-plugin' );

_ex( 'Post', 'backend', 'my-plugin' );

or

_x( 'Post', 'frontend', 'my-plugin' );

_x( 'Post', 'backend', 'my-plugin' );

This is my interim solution, maybe it will help.

More: how-to-internationalize-your-plugin

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.