Question

If I have a library available through packagist that could be used in WordPress plugin or theme development, how should I address multilanguage support if I have a few strings that could be localized?

I know that there has been some debate on composer usage in the WordPress world with very different views on it. (For example: 1, 2, 3)

But my question here is not about opinions on Composer in WordPress development, rather what would be the best practice to localize a library meant for WordPress which is not a plugin or theme. I would avoid making it a plugin, because it's not and it's not meant for end users. But just like many composer packages, as a development tool to be used in other projects.

Is it safe to use gettext wrappers provided by WordPress and meant for WordPress plugins/themes? That would save time but I'm not sure if this would work or create any trouble.

Was it helpful?

Solution

WordPress doesn't quite have a practice of localizing something that isn't core/plugin/theme.

My educated guess would be that it will work just fine with same concepts, but you will have to write custom loading logic. Use lower level load_textdomain(), since higher level functions are meant for plugins/themes specifically.

As long as you determine and load domain translation correctly, WordPress wouldn't care that calls are coming from the library context.

Licensed under: CC-BY-SA with attribution
Not affiliated with wordpress.stackexchange
scroll top