 can be easily translated into other languages. Actually, it's a way of coding in which the strings in your theme or plugin can be translated later without modifying the source code. That's the goal of internationalization. And localization is the subsequent process of translating the internationalization code. Usually, internationalization is denoted as I18N. That means there are 18 letters between I and N. And localization is denoted as KELTA-MEN. That means there are 10 letters between L and N. So why you should care about internationalization? This chart is taken from WordPress website a few days back. So in this, you can see that only this chart shows the total number of WordPress installations in the world according to the locales. So here you can see that only 45.7% of the WordPress installations are in English language. That means US English. So more than half of the installations are in language other than English. So that means you should always write translate into code if you want to reach your plugin or theme to a wider audience or a larger concept. So that's the reason we should do internationalization. So we can move to coding. First thing that you need to do is normally when you develop a theme or plugin in WordPress, you should write some header lines, like plugin name, other name, team name, et cetera. So in addition to these lines, you need to add two more lines. That is the text domain and the domain path. Text domain is actually a unique value assigned to each of your strings. And domain path is the path where your translations are saved. Also if you are planning to submit your plugin to the WordPress repository, the plugin slug should match the text domain. Plugging slug is the unique part of your URL that you get once your plugin gets approved in the WordPress repository. In this example, you can see that my plugin, the last URL, my plugin is the slug of this plugin. So the text domain should also be the same. Next thing we need to do is we need to load the translations. We need to write a function to load our translations on loading the plugin. So you can use the load plugin text domain function in WordPress. And you need to pass the text domain, text domain as the first argument and the languages folder as the last argument. So when this languages folder contains all the translations of your plugin. So whenever your plugin is loaded, all the translations will be loaded from this language folder based on the text domain. Similarly, in the case of themes, you need to call the load theme text domain function and it works the same as the plugin. Next thing is WordPress uses the get text libraries and tools for internalization. It's actually a tool used widely in the open source world. And it's used to buy a lot of applications in the world for internalization. We can see some string functions. This is an example of a get text function. All the get text functions start with that underscore. Here you can see that the first function starts with two underscore. And the function contains two arguments. Actually, this means that the first one, first argument is the string that needs to be translated. And the second one is the text domain. It's a text domain. This, actually, this means that the string in the first argument belongs to the text domain, which is the second argument. Normally, if we want to print something in PSP, we would write something like echo the string. But if we write like this, it cannot be translated. In order to translate this, we need to convert it into a get text function. You can see the converted function below, echo and the function and the string. So here, what happens exactly is, if a translation is found for the string in the first argument, then it will echo the translation. If no translations are found, then it will echo the same string. It will output the same string. Also, there is a shortcut for the echo function in get text. It's underscore-y. So normally, we use the underscore-y function instead of the echo function to print strings. And next thing you need to notice, you should never use variables in text domain and strings. Because get text cannot execute or get text cannot get the value of the variable. So you should always use plain text only in the text domain. But in the case of string path, the second example, sometimes we need to output strings like that. So in that case, sorry, sometimes we need to use variables. So in that case, you can use the printer function for the sprinter function in PSP. Next is another function, underscore-n. It's actually used to display strings based on plural or singular. The first argument of the underscore-n function is the singular text. And the second argument is the plural text. So based on the value of the count, it will display either the singular or plural value. Another example of getX function is the underscore-s x function. It's actually used to display content based on the context. So the noun and verb of a verb may be the same in English. But in a different language, it may not be the same. So in that kind of cases, you can use the underscore-x function. Also, as you know, in WordPress, we have an SK function for escaping malformed HTML or script or prevent CSS injection and all. So the SK function in WordPress can be combined with all the getX functions. You should always use the SK function with the getX function. Then your code will be more secure. So I have only explained a few of the getX functions. There are lots of functions. You can get a complete list of getX functions from the WordPress Quotex. So as you have a basic idea of how to write translatable code, we can now move to localization. It's a part where it actually gets translated. So normally there are two kinds of plugins, as you know. The plugins that we create for our personal use or the plugins that we create for our clients. These are all private plugins. Also, there are plugins that we submit to the WordPress repository. It's actually a public plugin. So the localization steps for these two plugins are different. So first we'll look at how to localize a private plugin. So first you need to understand three basic files, port file, PO file, and MO file. You can look into details of these files. The port file actually contains all the strings in your plugin or theme. This is usually generated using I18 rules. There are lots of I18 rules available. The most common one is the make port tool. It's a command-layer utility. Using it, you can generate port file. Also, there is a tool called PO edit, and there are lots of other tools to generate this file. Actually what these tools do is these tools will scan your entire theme or plugin directory, and will extract all the strings in the getX functions. So it will get all the strings in your code. This is a sample port file. Here we can see file names and the strings inside that file. So once you generate a port file, you can share it with a translator. And the translator can enter his translations and save it as a PO file. So for each file, there needs to be a separate PO file. Also, the PO file should be named using the correct locale. Locale means the area code and language. It's a combined code of area and language. For example, ENUS is the locale for US English, American English. EN underscore GB is the locale for British English. So also, the MO file should be named in the format plugins like hyphen, language locale. Here in the example, plugin is the slug and ELUS is the locale. This is a sample PO file for the Malayalam language. Here you can see that the port file and PO file are exactly the same. The only difference is this file contains the translations. Next is the MO file. So this is the actual file that the system reads to get your translations. So we need to convert every PO file to an MO file. The port file and PO file are used to by developers and translators. But the only file used to be the system is the MO file. This file can be generated using a tool called MSGFMT, it's a commanding utility available for both Linux and Windows. And once this file is generated, you can place it in the teams or plugins language folder, which is the folder I have explained in the first slide. So when the plugin is loaded, it will load all the translations from this file. Also, there are many tools available to generate all these three files. The most common one is the PO edit. It's available in a free version and a paid version. Using this PO edit, you can generate port file, PO file, MO file, all the files can be generated. And we can also use WordPress plugins to generate these files, like the most common ones are the local translate, WPML string translations. And there are lots of other plugins. So the advantage of using the plugins is that not only you can generate these PO and MO files, but you can also do all the translations from the WordPress dashboard itself. So if you create an account for your translator, you can log into your WordPress website and do the translations from the WordPress dashboard itself. That's the advantage of using plugins. So that is how you will organize a private plugin. In the case of a public plugin, actually, you don't need to do much. You just confirm that everything is coded correct, like the text domain is defined in the header, as I have explained in the first step, and the load text domain is called correctly. If everything is correct, you can submit it to WordPress and once it is approved, people from all over the world will translate and you can sit back and relax. So actually, this is done by translation contributors. So we can have a look at how these translation contributors work. Actually, the translation contributors in WordPress is called Polyglot's team. They are responsible for ensuring WordPress is available in the sense of language and many more regions. Also, the role of them is to release quality and consistent translations. Currently, WordPress is available in more than 200 locales. Actually, anyone can become a translation contributor. If you know more than one language, you can also become a translation contributor. You just need to sign up at WordPress, you just need to create an account at WordPress.org and you can log in to translate.wordpress.org. Once you log in, you will get a screen like this. Actually, when you take the site itself, you will get a screen like this. Here, all the available locales, that is, the local in which WordPress is available will be displayed. From this, you can choose one local and start contributing to the translations. Or you can search in the search field and do the... So once you select a local from this module, you will get a screen like this. Here, I have selected Malayalam locale. The official code for Malayalam locale is ml underscore ia. Once you select a locale, you will get all the projects inside that locale. For example, here you can see WordPress themes, plugins, et cetera. WordPress is the WordPress core CMS. So here, WordPress is selected, so it will display all the versions of WordPress. So from this, you can select a version and start contributing to that. And also, there are themes and plugins. If you click on themes, you will get access to all the themes in the WordPress repository and you can start contributing, start selecting one of them and start contributing to that. Similarly, it's a case with plugins. You should note that there are more than 54,000 plugins in the WordPress repository and I think more than 31,000 themes are available in the WordPress repository. This is the screen that you get once you have selected a module to translate. Here, I have selected a module of the WordPress core 5.0 version. So once you select a module, you can see that the total number of strings and the untranslated number of strings and the strings that are waiting for approval. Here, we can see that actually there are two columns. The first column contains the strings from the source code, the strings extracted from the source code. And the second column contains the translations contributed by users. So, you can see that one of the editor teams, one of the text is not translated. You can just double click there and a text area will open and you can enter your translations. Once you have entered a translation, you have also become a translation contributor. So, all the translations need to be approved by PTE. PTE means project translation editor. For each plugin or team, there will be a PTE team. So, one of the team members should approve your translations. Also, there is a team called GT. That means global translation editors. They can also approve your global translation editors are actually responsible for a complete module, sorry, complete locate. So, they can also approve your translations. Both GTE team and PTE team can approve your translations. So, once the translations are approved, it will be added to the corresponding module. That's how it works.