Internationalization of code snippets

[s3nL7n]

Hi, I'm new to Genesis, but not to WordPress.

I am wondering why most of the code snippets you give in the documentation and tutorials do not come internationalized?

Take for example a tutorial such as How to customize the Return to Top of Page link in the Footer

If I use that to the letter, then how will it look on a multilingual website?

Is there a really useful source that takes into account that 75% of the global online population actually uses the internet in different languages than English?

[NicktheGeek]

The main reason we don't internationalize the snippets we provide is because it will not be part of the pot, po, and mo files. This means the end use will have to rebuild the pot, po, and mo file to use the translatable strings. Additionally, the text domain would have to be updated for each child theme, which really makes the whole thing a waste of effort because the translation strings wouldn't work till much more work was done.

This means that the translation from the code snippets we provide is typically best handled by changing the string directly, if it is desired to make it multilingual, users that have the experience required to rebuild the pot, po, and mo files should be able to convert the strings to translatable strings using their child theme text domain.

[s3nL7n]

Hi Nick, thanks for your reply. That makes sense, but unfortunately to a certain extent only.

To illustrate this: I am using WPML to make my sites show in two or more languages. With it there are two options for translations, one is by using the theme's .mo file in which case your explanation makes fully sense.

However, WPML also offers the option to take care of the translations itself. How that works is that WPML scans the entire theme (and parent theme and plugins) for strings that have been internationalized.
As you will understand, now your explanation all of a sudden doesn't make sense at all!

Therefore I would like to propose to internationalize all strings from now on. This should not be some new feature, it should be(come) common practice.
For more information see my recent guest post on WP Candy

[NicktheGeek]

Thanks for the recommendation, however, your reason only works if everyone also agrees to use WMPL. If the end user is not, and they copy the code expecting it should be translatable out of the box ... but are mistaken to find it isn't and would require significantly more work on their part, or just type their own language in. Additionally, 90% of the code provided is intended to be exemplar, to allow users to change it to their own needs.

Where, someone using WPML can add __( '' ) around the code and be done with it.

I agree that the themes and plugins need to be translatable, however code snippets that are intended to be used as a template for customization, that should be used as the end user needs without any more markup than is needed, confusing the users looking for simple code they can adapt.

[s3nL7n]

unfortunately not all strings can be internationalized by

adding __('') around the code and be done with it

what I do understand from your answer however is that StudioPress cannot care less whether or not their framework is and/or can be used in a non-English environment.

That, I find the most useful information I can extract from this thread...

[NicktheGeek]

The framework is translatable and we take great effort to make sure it is, that the pot files are updated correctly with each update, and have dedicated community members that provide up to date translations.

This is not a question of StudioPress not caring that the framework is used in the international community. This is separate and the strings can be very easily translated as they are used, or made translatable by the end user.

These strings are not part of the framework, and making them translatable just doesn't work for users that aren't using a specific premium plugin unless the end user goes through much more work.

That is not reasonable to expect us to put every conceivable sting into the file for translation. No one would ever suggest that. It isn't reasonable for us ot assume the end user is going to use WPML or is willing and able to rebuild their pot file and make a new mp/po file.

It is reasonable to put the code out there in the simplest way possible, and allow the end user to adapt it to their needs.

We don't assume every user actually wants the return to top link to say "Return to Top." They might just want "Top" or any number of other things. The code is there so they can go "ok this says "Return to Top" but I want "Top" so I'll change that. If they want to translate to any other language, it works. If they want multi lingual, then they will have to adapt the code to that.

You are asking that the code be made more complex, when many users will have no idea what those __(), _x(), _e() .... functions are doing. It will make teh code much less acsesible, and that is a bad thing.

Yes, I understand you want it easier for you, but updating it for someone that is trying to use multilingual is a simple process. Asking your average user that is happy with a single language, be is English, Greek, Chinese, whatever, to figure out translatable strings and everything else is going on, that is not reasonable.

Again, please read very carefully right here:

StudioPress is dedicated to making the Framework fully translatable for the international community.