Internationalisation

[johnbillion]

The admin message in the plugin isn't translatable in its current form.

[coenjacobs]

Good point. I'm not sure how I can use the WordPress Internationalisation powers in this library though and we'd also have to bundle translation files as well. Not impossible, but makes it for the implementing parties not using Composer slightly harder to do. Any ideas for this?

[afragen]

#13 makes the message able to be internationalized but with no text domain.

[obstschale]

How about not using your own textdomain but instead use the plugin's textdomain ? That would mean everybody who uses the lib needs to translate the notice herself but I think it would be easier than loading a separate textdomain.

How could you achieve that?

I would pass my plugin's textdomain with the required PHP Version to the contstructor and use that new variable as textdomain in the lib. Surely, a fallback should be provided.

[coenjacobs]

Although that's a good idea, here is a reason why I would not do that (from Mark Jaquith's blog post):

See, PHP isn’t the only thing that needs to parse out your translatable strings. GNU gettext also needs to parse out the strings in order to provide your blank translation file to your translators. GNU gettext is not a PHP parser. It can’t read variables or constants. It only reads strings. So your text domain strings needs to stay hardcoded as actual quoted strings. 'my-plugin-name'.

[obstschale]

good to know. I didn't know that. Thx

[afragen]

Here's a starting point #19. Still need to figure out how to handle the text domain.

[grappler]

That information from Mark's blog is incorrect. https://ulrich.pogson.ch/string-text-domain-must

What if we passed the string as variable that could be overridden and use the text as the fallback. e.g.

$updatePhp = new WPUpdatePhp(
    '5.4.0',
    sprintf( __( 'Unfortunately, this plugin can not run on PHP versions older than %s.', 'text-domain' ), $this->minimum_version ) . ' ' . __( 'Read more information about <a href="http://www.wpupdatephp.com/update/">how you can update</a>.', 'text-domain' )
);

[coenjacobs]

In #42 I have setup the majority of the structure to make this library translatable through the plugin that is embedding the library. A couple final notes that I'd like to discuss here:

• Keep strings the way they are now, or split them up in two for each notice? No doubt, in other languages, the sentence structure isn't so similar as it is in English. In the sentence Unfortunately, %s cannot run on PHP versions, the variable can easily be replaced by either $plugin_name and this plugin. Would it be helpful for translators to split these up in two strings, on for using the plugin name and one for using the default placeholder this plugin?
• The same goes for the recommended notice. This might even be more complicated, as that string starts with the plugin name or placeholder. Any ideas on this?

[obstschale]

I would not use this plugin as string, because that general term might be misleading. If I activate multiple plugins and the notice only says this plugin I have not idea which plugin it means.

The rule of thumb for internationalization. Don't split sentences in different strings. That makes it hard for translators. If you have multiple variables in one string use numbered arguments.

sprintf( __('The plugin %1$s does not work with PHP version %2$s.', 'textdomain'), 'sample plugin', '5.3');

[coenjacobs]

Thanks for the suggestion, @obstschale. The thing that makes this a little more complicated (yet, I'm not opposed to it), is that this requires all plugin developers implementing this library, to set their plugin name. This was optional so far. Again, I'm not opposed to making it mandatory, but I do want to mention it in this conversation as something we need to be aware of.

[obstschale]

I see. I was not aware of that. If you want to keep a default string, I would recommend to keep them separate. That means translator would have to translate 2 strings, but I think it is saver. this plugin might change the wording in some languages.

[coenjacobs]

I have decided to make the plugin name a mandatory argument for this library. It improves the overall user experience and we should not fall back to a vague 'this plugin' description. After all, this is a major new version and implementing the new argument is only a small change required for developers updating to the new version of the library. Thanks @obstschale for thinking this through with me. Merged #42 into 2.0 release branch and closing this issue.