Translation support

[cfoellmann]

It is nice that functions like __() and _e() are being used but using a translation for the library is "complex".
Since I am will need it soon I will have a look at how to do it best. Will post sample code and potentially PRs here.

[cfoellmann]

A nice way to make this library translatable is this https://github.com/WebDevStudios/CPT_Core/blob/master/CPT_Core.php#L253-L265

[GaryJones]

I think the reference has changed since you linked to it.

I think there's a wider issue here though. Currently, if TGMPA is included in a theme, then that theme can generate a .pot with the TGMPA strings, but they may not be applied since TGMPA has a PHP variable for a textdomain. If they exclude it, then they don't appear in any .pot file. I think we need to be providing the .pot, .po and .mo (GlotPress install somewhere found via translate.tgmpluginactivation.com) for TGMPA ourselves, and then have the textdomains as tgmpa or tgm-plugin-activation.

[cfoellmann]

A lasting reference is: https://github.com/WebDevStudios/CPT_Core/blob/df1b621bcb03c6a96a13204940600a11b6a62b82/CPT_Core.php#L309-L322

The textdomain is not a var (anymore), right? __( 'Install Required Plugins', 'tgmpa' )
I think opening a new GlotPress is not the best way to go. http://wp-translations.org/ might be an option.

[jrfnl]

@GaryJones I believe having TGMPA native language files is not the right way to go. Some text string now literally say 'theme' while the library may also be included in plugins, so leaving the providing of the language strings up to the implementing theme/plugin makes a lot of sense.
How that is done, however, might need another look, but most of the current implementation of it in the develop branch (with the strings being passed via the config), makes sense to me.
The only problem you may then run into is conflicting translation between multiple implementations in use in the same WP client install.

[GaryJones]

If a theme and several plugins in an install all use TGMPA, then that's lots of the same strings that need translating.

If we did it ourselves, providing the localisations as well, then that's a whole bunch of strings that can be excluded from the theme and plugin .pot files. We translate it once, correctly, and load the textdomains from the right location, and those that include that include TGMPA moving forward can include the languages folder too.

[GaryJones]

https://ulrich.pogson.ch/future-pot-generators from @grappler also suggests TGMPA having it's own language file(s).

[grappler]

I do think that libraries should manage their own translations but it is not always so easy. The time is would work great is if a theme or plugin was using composer to define the dependency and loading all of the files.

The themes on WordPress.org are only allowed to define two text domains. The first for the theme and the second for a framework. If a theme is using a settings framework and a TGM then they would already have three text domains.

Another factor that needs to be taken into account that one day WordPress.org will offer GlotPress projects for every plugin and theme. As Makepot.php does not look at the text domain all of the strings will be added to the project anyway.

My recommendation would be to would be to define all of the strings in $this->strings and then let the theme/plugin author internationalize the strings. The string in $this->strings should not be internationalized.

[jrfnl]

Closing as loading of native translations has been added in dev via #521.

For those publishing themes via wp.org, if you download using the new Custom TGMPA Generator, will change the text domain to the theme's and will defer to the theme's loading of the text domain (and remove the TGMPA load call).