Category: ClassicPress

This post is part of the sub-series on Internationalizing a ClassicPress plugin which is part of the Internationalizing a ClassicPress plugin series.

A text domain is a unique identifier which makes sure ClassicPress can distinguish between all loaded translations and apply the correct one.

The text domain should be a unique string, not used by any other translation (which would include plugins and themes) and so is recommended to match the plugin slug. So if you have a plugin with the slug of my-classicpress-plugin the text domain should be the same.

If the text domain matches the plugin slug, ClassicPress does not require the text domain to be defined in th plugin header (although it is very much recommended that it does i order to avoid collisions with other plugins or themes), but if the text domain is different to the plugin slug, then you need to include the following highlighted line in the header:

/*
 * Plugin Name: My ClassicPress Plugin
 * Author: Ian Grieve
 * Text Domain: my-classicpress-plugin
 */

One important point to remember, is that a text domain cannot include underscores.

This post is part of the sub-series on Translating a ClassicPress plugin which is part of the Translating a ClassicPress plugin series.

ClassicPress uses the gettext libraries and tools for internationalization; gettext is an old and respectable piece of software which is widely used in the world of open-source.

The basics of how it works are:

• Developers wrap translatable strings in special gettext functions.
• Special tools parse the source code files and extract the translatable strings into POT (Portable Objects Template) files.
• Translators translate the strings in the POT file and save the translations into a PO file.
• PO files are compiled to binary MO files, which give faster access to the strings at run-time.

Over the next few posts, I’ll be stepping through what you have to do while developing an internationalized plugin to allow a POT file to be created.

This series is part of a wider series on Internationalizing a ClassicPress plugin.

In the first posts on the parent series, I explained what internationalization and localization are and, in this sub-series, I am going to explain the process of internationalizing a plugin developed for ClassicPress.

Continue reading “Internationalizing a ClassicPress plugin: Series Index”

This series if a is part of the Translating a ClassicPress plugin series.

In the last post I discussed why internationalization was important, but the follow on from this is when should a plugin be internationalized.

When developing a plugin, it is tempting to work on the functionality first and then go back to internationize the strings afterwards. When I started developing plugins, none of them were interationalized. When I started doing so, I had to go back and find all the strings and then wrap them in the relevant functions.

New plugins, I have internationalized from the beginning and this is much less work and also means there is much less opportunity to miss a string which going back afterwards makes quite likely.

My recommendation, is to internationalize your plugin from the beginning and thereby save yourself time and errors.

This post is part of the sub-series on Translating a ClassicPress plugin which is part of the Translating a ClassicPress plugin series.

ClassicPress is already used in many different countries where English is not the main language; and even where it is, there can be variations in the spelling of words. ClassicPress itself is internationalized and can be localized.

Plugins and themes developed for ClassicPress should also be internationalized so that they can then be localized. The developer who authors the plugin doesn’t have to do the localization (translations), but by internationalizing the plugin it means that others can easily translate the plugin without needing to modify any code.

By making translations easy to do, you increase the audience for your plugin as site admins can easily translate it into their sites language.

This post is part of the sub-series on Translating a ClassicPress plugin which is part of the Translating a ClassicPress plugin series.

Internationalization (often abbreviated as i18n as there are 18 letters between the letters i and n) is the process of developing a plugin so it can easily be translated into other languages.

Localization (often abbreviated as l10n as there are 10 letters between the letters l and n) is the process of translating an internationalized plugin.

If you are a theme or plugin author, you should regard internationalization (i18n) and localization (l10n) as a requirement for your ClassicPress projects.

I started using WordPress when I launched this blog back in 2011 and a couple of years later started writing plugins to add missing functionality. At the end of last year I switched over to ClassicPress, a hard-fork of WordPress.

As part of my transition to ClassicPress I created new versions of my plugins which added new functionality and improved security. I had already done some work to internationalize my plugins, but took the opportunity to improve this aspect as well.

Having done so, I thought that a series on how to internationalize and localize plugins might be a useful thing to write; while the series is targeted at plugins, as I am a plugin author, the principles are the same for themes.

This series will include a couple of sub-series as well as the core series; the index for all are below and will automatically grow as the posts go live.

Continue reading “Translating a ClassicPress plugin: Series Index”