does a translation (i18n) have to start from an english PO?

1 Views

i was wondering: it seems a translation must be a translation from english. I mean, the starting file is in english, then you do translations from that.

But what if say, I’m Italian? So the base language is Italian and the others are translations from Italian? Because it’s just this: i’d like to have the original PO file in italian and starting from there.

Read More

What’s teh way of doing it?

Post Views: 1

Related posts

Leave a Reply

2 comments

  1. Basically all themes out there are written in English, and localizations strings will look something like this _e( 'Some English text', 'domainname' );. Usually authors include a pot template with the theme. I qoute from the codex

    “POT (Portable Object Template) files
    The first step in the localization process is that a program is used to search through the WordPress source code and pick out every message passed into a __() or e() function. This list of English-language messages is put into a specially-formatted template file (POT file) that forms the basis of all translations. Generally, you can download a POT file for WordPress, so you shouldn’t have to generate your own. Separate POT files can also be made for themes and plugins, if the theme/plugin developer has enclosed all text in _() or _e() functions.”

    So to translate text into a language like Italian you have to create a po and mo file from the original pot template, and name it accordingly to the language.

    That said, you can create your own custom theme, and instead of using English, use Italian in you localization strings like this _e( 'Some Italian text', 'domainname' ). So your default language will be Italian without a language set in wp-config.php. Your pot template that you are going to create will now hold the Italian text instead of English as your theme is in Italian. The user can then translate from Italian to his own language by creating a po and mo template with the proper language name and texts inside.

    OK, now the debate, as stated in the codex, pot templates hold English language and I again quote from the codex

    “This list of English-language messages is put into a specially-formatted template file (POT file)”.

    I’m Afrikaans speaking, but for the sake of keeping to the world and wordpress standard language, I write everything in English, create my pot file, and from that I create my po and mo templates for the Afrikaans language.

    I personally think that one should keep to standards. It is up to everyone to honor or to dishonor these standards. I mean, take Afrikaans for instance, less than 1,5 million people around the world speaks Afrikaans, and beside Belgium and Dutch that might understand Afrikaans to some degree, no one else understand the language or the grammar. So basically, if you write a theme in Afrikaans, just a few people will be able to use it, as no one will be able to translate it to their foreign language.

    This is a problem if you are thinking of selling your theme. OK, it might work if you sell your theme to people that will be using the same language, but your market will be so small that it would not be the worthwhile.

    But as I stated, it is up to you to honor standard or not. I hopes this help

  2. Ok, I just add an answer to my own question to clarify all the story and solutions.
    This also serves for other lang-related issues.

    So, what I’ve got:

    • A native multisite installation
    • Every site represent a different language
    • Every site has it’s own theme, child of the main language
    • The main language is italian (it_IT)
    • it’s just a production custom theme so no need to distribute it

    Say we’ve got a parent theme called ‘parent-theme’ and a child theme called ‘child-theme’.

    The steps:

    IN THE PARENT THEME

    • in style.css add this line > Text Domain: parent-theme

    • in functions.php, in ‘after_setup_theme’ filter add:

      load_theme_textdomain( ‘parent-theme’, TEMPLATEPATH . ‘/languages’ );

    • in the theme folder, add a languages folder

    • in that folter add locale.mo files. I mean, for example, en_US.mo, fr_FR.mo, etc…

    The .mo files will be used by the wordpress translation functions (__(), _e()), etc..

    The .mo files are binaries that will be created from .po files (essentially the same of .pot), using some software like poedit or others (just google).

    The .po files will have this kind of content (sample form en_US.po):

    #: front-page.php
msgid "prodotti"
msgstr "products"

#: front-page.php
msgid "EVENTI"
msgstr "EVENTS"

#[etc....]

    Where # are comments, msgid is the original (main language) string (in this case the italian string) and msgstr is the translation. NOTE: case sensitive.

    The po files in theme/languages are meant to only have the translation definitions you need for your own needs on your theme (so can be very few), nothing more.

    Then you simply in your theme (and child themes) can use the translation functions (see wordpress codex) like __(), _e() and so on…

    So, I did nothing in the child themes, all the work is on the main theme. If you need specific context, just register the textdomain for the child theme (see http://codex.wordpress.org/Function_Reference/load_child_theme_textdomain), add a languages folder to the child theme, and add the po/mo files.

    NOTE: Keep in mind that the translation functions use get_locale() to choose the right .mo file form which to take translations. get_locale() checks the existence of WPLANG constant (eventually setted in wp-config.php) or other settings from admin, OR it takes what comes from the ‘locale’ filter. For my needs, I do not even set WPLANG.

    Finally, one could need to have different languages in frontend but the same language for the admin for all the sites in the multisite. If that’s the case, you set your admin language just from the general setting in admin. Then, in each theme’s functions.php:

    add_filter('locale', 'set_admin_locale');
function set_admin_locale() {
  return 'en_US';//or whichever language/locale you want in frontend
}

    Hope it will help people to get their way in all this mess. It’s not that difficult, but you need to put some order and that’s exactly why I just wrote this long answer.