시간과 공간 그리고 진실의 방

Woocommerce 와 WPML 환경하에서 PG를 갈라서 쓰고싶어서 쓰는 플러그인인데 상당히 융통성이 없는 플러그인이다.

그러니까 말인 즉슨, 무조건 기준이 상점통화를 기준으로 출발한다는 것인데, 

USD 1 $  = KRW 1210.00 \ 

이런 개념이라는 것이다. 변동가능한 값은 기준통화가 아닌 오른쪽의 가변변수로 놓여야 할 통화에 불가능 하다는 것.

얘네가 자동으로 환율전환을 하는 사이트로 2가지를 소개해주고 있는데, 걔네들도 결국은 실시간으로 데몬화시켜서 서버측에서 돌려다 쓰는 것인데다가, 그걸 JSON Format으로 던져다가 업그레이드 하는 수준이고

그거 가지고 달에 10달러 (약 만원) 씩 뜯어먹는다. 오지게 뜯어먹는다.

그런데 더 의아한건 거기서는 기준 통화 (Source)를 USD가 아니라 KRW로 바꿀 수 있는 기능을 이미 제공하고 있음에도 불구하고, WPML Multiligual 에서는 해당 부분을 지원하지 않는 다는 것이다.

결국은 쓸려면 커스터마이징을 거쳐야한다. 

WooCommerce Multilingual, includes support for running a multilingual e-commerce site with multiple currencies, independent of the site’s languages. You can set pricing using a configurable exchange rates map or per product. On the front-end, users will be able to switch between the different available currencies, like they switch languages.

Configuring currencies per language

It is possible to show specific currencies on specific languages and also configure default currencies for distinct languages. This is done on the WooCommerce -> WooCommerce Multilingual page, under the Multi-currency tab.

Multi-currency Settings

This helps with situations when products in certain languages need to be ordered only in a precise currency. Additionally, default currencies can be set for specific languages so, by default, the users will see product prices in a given currency when they switch to a different language on the front end. The Keep option means that the currency will not change when the language is being changed.

When a new currency is added it is being included by default on all languages and can easily be turned off using the appropriate checkboxes.

Each custom currency must have an associated exchange rate. This will be relative to the site’s default currency and can be changed anytime. When the exchange rate changes all prices in the custom currencies will change accordingly, except prices included in orders that have already been placed.

Payment gateways settings

By clicking on Edit currencies settings icon, under the Multi-currency tab, you can access the set of options related to currency display, exchange rate, and Payment Gateways options.

Currently, supported payment gateways are Paypal, Stripe, and BACS.

Since not all payment gateways accept all currencies you can define ways to automatically make a conversion before making the transaction in a supported currency.

Currency settings

On the checkout page, a notice will show what currency will be used in the transaction if it is different than the one already selected by the user. The total amount will also be displayed in the converted currency.

Payment notice on a checkout page

Using automatic exchange rates

WooCommerce Multilingual allows you to set up automatic exchange rates for your store. There are three options to set for this features.

Use the Exchange rates source to select the source of the exchange rates data. You can choose from two renowned services including Fixer.io and currencylayer.

You can set an additional Lifting charge percentage to adjust the final, effective exchange rate. This is useful for international transactions that may add additional charges.

The following is how the effective rate is calculated, based on the set lifting charge:
Effective Rate = Service Rate x (1 + Lifting Charge / 100)

Finally, you can also set how frequently the automatic exchange rates will be updated for your store. Updates can be set to happen on a daily, weekly, or monthly basis. By default, this is set to manual update.

Settings for the automatic exchange rates

Configure distinct prices for different currencies

WooCommerce Multilingual also includes the option to set custom prices in different currencies. These will be fixed and will override the prices automatically determined by the exchange rate.

Setting custom prices in different currencies can be enabled from the post editor, under the fields for Regular Price and Sale Price (for the default currency). These prices will override the prices determined automatically based on the exchange rate. To revert to using the automatic prices you simply have to remove the custom prices and update the product.

These prices will override the prices determined automatically based on the exchange rate. To revert to using the automatic prices you need to remove the custom prices and update the product.

Setting Custom Prices

A similar interface exists on the variable products editing screen with the possibility of adding custom prices for some, or all variations, or for some, or all custom currencies.

Orders currencies

Orders will have a specific currency associated with them. It is the currency that the user was using when placing the order. This will also be reflected on the back-end, where on the Orderspage, each order shows the total in the corresponding currency. On this page, it is also possible to filter the orders by currency.

Orders Filtered By Currency

Since all created orders will have a currency associated, the WooCommerce reports will be broken down by currency.

Reports Filtered By Currency

Adding a currency switcher to the front-end

Once you have added the support for multiple currencies, you should display a currency switcher in your site’s theme. You can display the currency switcher with a shortcode or as a hook.

Currency switcher shortcode

Shortcode: [currency_switcher]
Attributes: format (Available tags: %name%, %code%, %symbol%) Default: %name% (%symbol%)

The shortcode version is the most convenient when you display the currency switcher inline with WordPress content, for example in Content Templates, by the Views plugin.

Currency switcher as PHP code

PHP code: do_action('wcml_currency_switcher', array('format' => '%name% (%symbol%)'));

The other available parameter besides “format”:

• switcher_style: wcml-dropdown, wcml-dropdown-click, wcml-horizontal-list, wcml-vertical-list

Outputs a basic drop-down menu with currency codes for option values. The client’s current currency or the configured default currency for a specific language will be auto-selected.

Using custom switchers

Besides these default switcher_style options, you can also use your custom ones, defined by the custom currency switcher you design using template files. In this case, you need to use the correct slug that identifies your custom currency switcher.

The slug for your custom switcher is generated depending on the sanitized name of your template, as defined in its config.json file, and the template’s location:

Let’s consider the following example:

• The name of your custom currency switcher is “My custom switcher”.
• You are using the Twenty Seventeen theme and the template files for your switchers are located in the theme’s folder.

The slug to use with your custom switcher is twenty-seventeen-my-custom-switcher, as shown in the following example.

Using custom currency switcher in PHP templates

The PHP code version is best when you manually add the currency switcher to PHP templates.

Sample of currencies switcher display on the frontend

Currency switcher widget

The currency switcher can also be added to a template as a standard WordPress widget.

Currency switcher options

Options for the currency switcher can be configured on the Multi-currency tab of WooCommerce Multilingual main settings page.

Currency switcher options allow you to:

• Preview how the switcher will look like on the front-end before applying changes.
• Set the switcher style.
• Arrange the order of currencies in the switcher using drag-and-drop.
• Adjust the output of the switcher.
• Enable or disable the showing of a currency selector on the product page template.

Currency Switcher Options

Adjusting the output of the switcher

You can customize the template used for the currency switcher by using the four parameters:

• %name% – full name of the currency, for example “Euro”
• %symbol% – the standard symbol that represents the currency, for example “$” or “€”.
• %code% – the standard code that represents the currency, for example “USD”, for United States Dollar.
• %subtotal% – total costs of the current order (basket), without shipping costs and additional taxes. Subtotal is the formatted price and includes the currency symbol positioned according to the currency options set in WooCommerce settings.

Starting with version 3.9, WooCommerce Multilingual allows you to use the following HTML tags to customize the output of the switcher: img, span, em, strong and u. Please note that these tags can only be used when the currency switcher style is set to List of currencies. This stems from the official HTML standards for the select tag.

Currencies options and rounding rules

Currency Rounding Rules

Besides the exchange rate, it is possible to configure, for each separate currency, things like the currency position, separator for thousands, decimal separator and number of decimals – similar to how these can be defined for the default WooCommerce Currency in the standard WooCommerce screen.

When you set pricing per currency, you can have WooCommerce Multilingual to auto-convert the prices, while keeping them “elegant”. This is possible with the use of rounding rules that can be configured next to the general currency options.

The prices that are determined automatically can be rounded to the nearest integer.

Increment for nearest integer:

• 1454.07 becomes 1454 when this value is 1
• 1454.07 becomes 1450 when this value is 10
• 1454.07 becomes 1500 when this value is 100

Autosubtract amount: the value to be subtracted from the amount obtained previously.

For 1454.07, when the increment for the nearest integer is 100 and the auto-subtract amount is 1, the resulting amount is 1499.

Developer information – using low-level hooks to setup your own multi-currency logic

WooCommerce Multilingual defines a set of filters and hooks that can be used by 3rd party plugins to implement multi-currency logic when WooCommerce and WooCommmerce Multilingual are set up and running. With this, the users will be able to see prices in their preferred currency (the price amounts are being determined based on the currencies exchange rates map). The orders will be placed in the currency that the user selects on the front-end.

우커머스 사용시에 원화에서 페이팔을 사용하게 해줄 수 있는 것이지만, Pro 플러그인을 끌어다 써야하기에 좀 의아한 부분이 있는 플러그인이다. 해당 부분에 있어서 Pro 플러그인을 쓸 수 없는 상황이라면, 네이버 환율 등을 php에서 끌어다가 파싱해서 써야하는 단점도 의외로 존재한다.

WPML에서 PG를 분리해서 사용하는 경우에는 사실상 쓸모가 없는 내용이였지만, 생각보다 유익해 보이기에 긁어온다.

페이팔 사용 설정

워드프레스 우커머스로 쇼핑몰을 운영할때 가장 기본적으로 설정하는 것이 상점의 기본 통화입니다.
이 상점의 기본통화는 상품진열과 함께 결제 과정에서 기본이 되는 통화를 설정하는 것입니다.
이 때 한국 쇼핑몰의 경우 원(￦) 단위를 설정합니다.

<우커머스 쇼핑몰의 기본 통화 설정>

이 경우 우커머스의 결제 방법 중 페이팔은 활성화 되지 않습니다.

<우커머스에서 한국 통화 설정시 페이팔  비활성화>

이 때 아래의 코드를 사용중인 차일드 테마의 functions.php 파일 하단에 입력하면 페이팔 사용이 가능해 집니다.

add_filter( 'woocommerce_paypal_supported_currencies', 'add_currency_krw'); function add_currency_krw( $current_currencies ) { array_push( $current_currencies, 'KRW' ); return $current_currencies; }

<결제수단에 페이팔 사용 설정화면 활성>

결제 설정

위와 같이 페이팔이 결제 수단에서 가능하도록 설정 해 두더라도 문제가 있습니다.
페이팔에서 원화를 지원하지 않기 때문에 실제 페이팔 결제로 넘어갈 때 현재 상품의 가격이 페이팔이 지원하는 통화로 환산되어 넘겨지지 않는다는 것입니다.
다시 말하면 상품의 가격이 10,000원(￦) 일 경우 페이팔 결제로 넘어갈 때 10,000 이라는 값과 페이팔에서는 원화(￦) 결제가 없으므로 기본 통화인 $가 합쳐져서 10,000$ 가 결제화면에 나타나는 것입니다. (참고 현재 페이팔이 지원하는 통화)
이 문제를 해결하기 위해 결제가 넘어갈 때 상품의 가격을 페이팔이 지원하는 통화 단위로 환산 해 주는 기능이 필요합니다.

이 때 사용할 수있는 간단한 플러그인이 PAYPAL CURRENCY CONVERTER PRO FOR WOOCOMMERCE 입니다.

플러그인을 설치하면 관리자 메뉴 “우커머스”의 서브메뉴로 “Exchange Rtae”가 추가됩니다.

< PAYPAL CURRENCY CONVERTER PRO FOR WOOCOMMERCE 플러그인 설치후 메뉴>

안에서 통화의 환율을 설정해 줍니다.

<페이팔 결제를 위한 통화 환율 설정>

기준이 되는 통화(현재 기본설정 되어 있는 원)를 목표통화(달러)로 환전하기위한 비율을 적용하는 것입니다.
환율은 내가 임의의 값으로 입력해도 되고, 야후 Finance 등의 도움을 받을수도 있습니다.

페이팔 결제의 문제

위에서 처럼 설정하면 페이팔 결제가 가능해 지고 결제시 페이팔에서 지원하는 기본 통화인 달러로 환산된 가격을 결제 받을 수 있게 됩니다.

하지만 이 결제 방법은 쇼핑몰의 점주가 페이팔 한국계정을 사용하는 경우, 같은 한국 계정을 가진 사람에게 결제를 받을 수 없습니다. 현재 대한민국에서의 규정이 그렇습니다.(페이팔로 한국인 상호간 거래 불가)

<한국인 상호간 페이팔 결제 수단 사용 불가>

그러므로 해외 거주하는 사람이 한국의 원화 결제 수단이 없는 경우, 페이팔로 결제를 할 수 있도록 할 때 제공 할 수 있는 방법입니다.

참고

이 글에서 소개 한 것 처럼 원화를 달러로 환산해서 결제 받을 수 있도록 하는데 사용 할 수 있는 방법으로 WooCommerce Currency Switcher 플러그인을 사용 할 수도 있습니다.
이 플러그인은 환율을 변경하는 스위치를 웹사이트에 표시하고, 사용자가 스위치 변경시 선택한 통화로 환전된 가격을 우커머스 상품에 표시하며, 결제시에도 변경된 통화를 사용하도록 해 줍니다. 여러가지 통화를 동시에 제공할수 있어서 필요시에 유용합니다.

The Popup Settings -- Triggers option allows users to set a trigger and a cookie on a popup.   

This article describes the 'Cookie' option in the popup editor.  Refer to the related article below for information to set a popup trigger.

Related article: 'Triggers' options settings.

Article Contents

• Definition of Terms (triggers and cookies)

• Add a New Cookie

• 'Cookie Settings -- General' option settings box

• 'Cookie Settings -- Advanced' option settings box

• Options to Set and Link a Cookie to a Trigger

• Set and Link a Cookie When Adding a New Trigger

• Set and Link a Cookie When Editing an Existing Trigger

• Set A Browser Cookie When Submitting A Form

• Set a Browser Cookie 'On Click' Inside a Popup

Definition of Terms

Triggers -- These are 'events' that cause a popup to display in the browser. A popup requires at least one trigger in order to display, and may accept multiple triggers. 

Cookies -- These control the repeated display of popups in the browser. To work, they must be set and linked to a popup trigger.  Cookies are assigned an identification (ID) number formatted as 'pum-{integer}'. The use of one or more cookies with a trigger is optional, but often recommended. 

By default, cookies are valid for a term of 1 month,  which can be changed by plugin users to a different value. Popups controlled by a cookie can redisplay before they expire if the popup cookie is cleared from the visitor's browser. 

[   Back to top ]

Add a New Cookie

When the button labeled 'Add New Cookie' is selected, a popup labeled   'When should your cookie be created?' will appear.  Five (5) cookie setting options are provided with the base (free) version of Popup Maker.  The plugin default is set to the first option value, 'On Popup Close'. 

They include:

1. On Popup Close -- A cookie is set in the browser when the popup is closed (default);

2. On Popup Open -- A cookie is set in the browser when the popup is opened;

3. Subscription Form: Successful  -- This cookie option is intended for use with our MailChimp Integration plugin extension to Popup Maker.  It is also available for use with the Popup Maker 'Subscription Form' shortcode integrated with a 3rd party email marketing plugin or application registered with Popup Maker.  

Plugin users of either  Ninja Forms, GravityForms, or Contact Form 7 should continue to use either of the first 2 cookie options above, plus their respective Popup Maker 'form submit success' cookies (see 'related article' links below). 

Related article: Ninja Forms Submit Success integration cookie

Related article: GravityForms Submit Success integration cookie

Related article: Contact Form 7 Submit Success integration cookie

4. Subscription Form: Already Subscribed -- This cookie option is intended for use with our MailChimp Integration plugin extension to Popup Maker.  It is also available for use with the Popup Maker 'Subscription Form' shortcode integrated with a 3rd party email marketing plugin or application registered with Popup Maker.  

5. Manual Javascript -- Select this option when using form plugins for which Popup Maker does not have a specific integration:

a)  All other WordPress form plugins.

b)  MailChimp for Wordpress,

This cookie option setting is also available to set a browser cookie when selecting content inside a popup 'on click'. See the section  'Set a Browser Cookie 'On Click' Inside a Popup' below for details.

Each of the 5 cookie options listed above is described at length in the related article link below. 

Related article:  'Cookie Settings and Features'.

[   Back to top ]

'Cookie Settings -- General' option settings

Upon adding a cookie option, the 'Cookie Settings -- General' option settings box will appear. 

The custom fields shown include:

Cookie Name -- Popup Maker automatically assigns a cookie an ID number formatted as 'pum-{integer}'. This ID is used to link a cookie to a trigger. 

Cookie Time -- By default, cookies are valid for a term of 1 month. This can be changed by plugin users to a different value. Acceptable units of time include: 

• seconds,
• minute(s),
• hour(s),
• day(s),
• month(s), and 
• year(s)

[   Back to top ]

'Cookie Settings -- Advanced' option settings

Popup Maker provides some 'advanced' option settings, whose defaults seldom need to be changed.

The custom fields shown include:

Use Session Cookie? -- By default, this option is turned 'off'. Modern browsers can keep web pages (and browser sessions) open indefinitely, even when browsers and devices are not in use. We maintain this option setting for plugin version backward compatibility. Most plugin users have no need to turn the option 'on'. 

Sitewide Cookie -- By default, this option is turned 'on'. It applies Popup Maker cookies throughout a site, controlling the repeat display of popups on any site page. 

[   Back to top ]

Options to Set and Link a Cookie to a Trigger

Cookies can be set and linked to a trigger either: 

1. when adding a new trigger, or
2. by editing an existing trigger. 

Set and Link a Cookie When Adding a New Trigger

1. From the 'Trigger' option settings tab, select the button labeled 'Add New Trigger'. 

2.  From the popup titled 'Choose what type of trigger to add?', select the checkbox labeled: 'Would you like to set up a cookie as well?'. 

3. Choose from among the five (5) cookie options presented below, then select the 'Add' button to add the trigger and link the cookie. The plugin default selection is set to 'On Popup Close'. 

4. Depending on which trigger is selected, the matching option setting box will appear: 

'Click Trigger Settings -- General' option settings,

 or  Time Delay Settings -- General' option settings.

In the 'Cookie Name' custom field, Popup Maker automatically generates and assigns the trigger a new cookie with an ID of 'pum-{integer}'.

5.  The trigger is set and linked to a new cookie. In the example above, a 'Click Open' trigger is set, and linked to a cookie set to launch 'On Popup Close'. The cookie has an ID of 'pum-40'.

[   Back to top ]

Set and Link a Cookie When Editing an Existing Trigger

1. To add and link a cookie to a trigger, edit an existing trigger. Select the 'pencil' icon from the 'Popup Settings -- Trigger' option settings tab. 

2a. Edit an existing 'Click Open' trigger --  The 'Click Trigger Settings' option settings popup will appear. On the 'General' tab, select the custom field labeled 'Cookie Name'.  An 'Add New Cookie' option will appear. Select the option to add it to the custom field, then select the 'Update' button. 

2b. Edit an existing 'Time Delay / Auto Open' trigger -- The 'Time Delay Settings' option settings popup will appear. On the 'General' tab, select the custom field labeled 'Cookie Name'.  An 'Add New Cookie' option will appear. Select the option to add it to the custom field, then select the 'Update' button. 

Note: The process described above in Step 2 for the 'Click Open' and 'Auto Open / Time Delay' triggers is the same for any premium trigger available as a  plugin extension to Popup Maker. 

3.  The plugin will prompt with a popup labeled 'When should your popup be created?'.  The plugin default option is set to 'On Popup Close', with four (4) additional option settings available. 

Either accept the plugin default option, or select a different option, and then click the button labeled 'Add' to move to the next step. 

5.  The 'Cookie Settings -- General' option settings box will appear displaying two (2) custom fields; 'Cookie Name' and 'Cookie Time'. 

'Cookie Name' is a cookie with an identification (ID) format of 'pum-{integer}' (for example, 'pum-40').  

'Cookie Time' is an expiration term for the cookie. The plugin default value is 1 month, which can be changed to a value that ranges from minutes to years. 

To accept the values for 'Cookie Name' and 'Cookie Time', select the 'Update' button. 

6.  In the image above, a 'Time Delay / Auto Open' trigger is now linked to an 'On Popup Close' cookie via the cookie ID of 'pum-40'. 

[   Back to top ]

Set A Browser Cookie When Submitting A Form

Popup Maker adds a 'form submit success' cookie option for any of the WordPress form plugins listed below when they are activated with our plugin.

• Ninja Forms, 
• Gravity Forms, and 
• Contact Form 7

Note: Popup Maker is a Ninja Forms affiliate. We provide support for each other’s products. 

Any WordPress form plugin other than those listed above should set a 'form submit success' cookie via the 'Manual JavaScript' option setting. See the related article link below for details.

Related article:   Close Popup and Create Cookie When a Form is Submitted 

[   Back to top ] 

Set a Browser Cookie 'On Click' Inside a Popup

The 'Manual JavaScript' cookie option was discussed previously in the section titled  'Add a New Cookie' (list item #5).  It can be used to set a browser cookie on form submit success with any WordPress form plugin other than the 3 plugins with which Popup Maker directly integrates. 

This cookie option can also be used to set a browser cookie 'on click' of any content displayed inside a popup. For example, a popup displays by a 'Time Delay / Auto Open' trigger. The popup contain 2 images, and the visitor is encouraged to click on one or the other image. 

The 'Manual JavaScript' cookie option can be used to set a browser cookie 'on click' when either popup image is selected.  See the related article link below for details, including cookie option setting and custom code. 

Related article: Create Cookie On the Click of an Element Within Your Popup.

[   Back to top ]

Did this answer your question?

Yes 

WPML enables you to translate the texts coming from themes and plugins you use in your sites. This allows you to have a completely translated site. Additionally, it allows the users of your site’s administration area to use the interface in their native language.

Localization options and performance optimization

You can find the settings for theme and plugins localization on the WPML -> Theme and plugins localization page.

Main theme and plugins localization options

WPML allows you to create translations for texts in themes and plugins in three ways:

• Use only String Translation.
• Use String Translation but load .mo files as a backup.
• Don’t use String Translation but only load the .mo files. This is a good option when you already have a theme with the translations you need.

Theme and plugins localization options can significantly impact the performance of your site. WPML version 3.8 and later automatically suggests the most efficient localization options.

Message prompting to use WPML’s String Translation only

By default, it prompts you to use WPML’s String Translation only, by loading all the translations from the .mo files into the database. This importing is done once and after it is complete (it can take a while, depending on your site), the performance will be optimal in regards to theme and plugins localization.

String Translation announce that it will start loading all the translations from the .mo files

String Translation is loading all the translations from the .mo files

Finally, String Translation warns you once this process has finished.

String Translation loaded all the translations from the .mo files into the database

Translating the theme and plugins using WPML’s String Translation

This option requires WPML’s String Translation module, available as a part of the Multilingual CMS account type.

As we already mentioned, when using String Translation to translate the theme and plugins texts, you can select to load the .mo files as a backup or not.

When loading the .mo file as a backup is selected, WPML will fall back to .mo file translations if those exist in your theme and plugins. This means that if you see a translated text string in your site which does not seem to appear under String Translation, it is very likely that the translation comes from a .mo file in your theme or plugin.

When either of these options is used, WPML scans the theme and finds the texts that can be translated. It reports what it finds and let you enter translations, right from within WordPress.

Since version 3.8 and later, by default, WPML automatically prompts you to scan for new texts in your site whenever a theme or a plugin is activated.

Scanning themes for texts

Scanning themes for strings

You can also manually start the scanning of themes for texts. Select the themes to scan and click on Scan selected themes for strings.  WPML goes through all the files in the selected themes to extract translatable texts from them (texts that are wrapped with gettext functions).

The scanner shows how many strings were found in the theme and their translation status. You can translate them from the WPML -> String Translation page.

In the Localization options section, under Other options, you can find an option to Use theme or plugin text domains when gettext calls do not use a string literal. This option might be helpful if you are using a theme which uses gettext incorrectly.

Scanning plugins for texts

Similarly to scanning a theme for strings, WPML can scan plugins and find translatable strings.

Scanning plugins for texts

Select the plugins to scan and click on Scan selected plugins for strings.

Please note that there is a limitation with scanning the Must Use (MU) plugins. Usually, MUplugins consist of a single file and you can translate them normally. However, if the author has included sub folders which are called from the MU plugin, WPML String Translation cannot access them. This means WPML cannot scan and translate files contained in these sub folders.

Translating the strings

Administrators and Editors can translate theme and plugins texts on the WPML -> String Translation page.

Translating texts via WPML’s String Translation

To translate a text, use the search controls on the top of the page to filter the specific strings. Most importantly, select the domain (it should feature a theme or plugin’s name) whose texts you want to display and translate.

To manually translate listed texts, click the translations link for the text in question, enter the translation, select the Translation is complete checkbox and click Save. If you see translations of the text in question, marked in yellow, this is the translation coming from the theme or plugin’s .mo files. If you prefer, you can override them with your own, by selecting the Use my translation option and providing the translation in question.

You can also assign the selected texts and send them for translation by your designated local translators or professional translation service. For this, you need to have the WPML Translation Management module installed on your site.

Choose the strings to translate, the languages to translate them into and click on the button to Add to translation basket.

Selecting text strings to send to translation

From the Translation Basket tab of the WPML -> Translation Management page, you will then be able to select the translator and send the selected texts for translation.

Your local translators will be able to access the String Translation screen and translate just the ones that you’ve sent them for translation.

Specifying the locales for different languages

A locale is a code which determines which language variant to use for different languages. It is comprised of a combination of language and country.

For example “en_US” means American (USA) English and “en_GB” means English used in the UK.

The locales table in WPML is already pre-populated with the correct values for all popular languages. You should edit it only if you want to use a different language/country combination or if you have added your custom languages. For instance, the default locale for Spanish is “es_ES” (for Spain), but you can change it to Mexican Spanish by setting the Spanish locale to “es_MX”.

To edit the locales, go to the WPML -> Languages page and click the Edit Languages link found in the Site Languages section.

Locale settings

Getting Translation Files for WordPress Itself

In the past, you needed to use the Theme and plugins localization page to download the translations of WordPress core files.

Now, WPML does this automatically any time you add a language on the WPML -> Languages page or during WPML installation.WPML enables you to translate the texts coming from themes and plugins you use in your sites. This allows you to have a completely translated site. Additionally, it allows the users of your site’s administration area to use the interface in their native language.

Localization options and performance optimization

You can find the settings for theme and plugins localization on the WPML -> Theme and plugins localization page.

Main theme and plugins localization options

WPML allows you to create translations for texts in themes and plugins in three ways:

• Use only String Translation.
• Use String Translation but load .mo files as a backup.
• Don’t use String Translation but only load the .mo files. This is a good option when you already have a theme with the translations you need.

Theme and plugins localization options can significantly impact the performance of your site. WPML version 3.8 and later automatically suggests the most efficient localization options.

Message prompting to use WPML’s String Translation only

By default, it prompts you to use WPML’s String Translation only, by loading all the translations from the .mo files into the database. This importing is done once and after it is complete (it can take a while, depending on your site), the performance will be optimal in regards to theme and plugins localization.

String Translation announce that it will start loading all the translations from the .mo files

String Translation is loading all the translations from the .mo files

Finally, String Translation warns you once this process has finished.

String Translation loaded all the translations from the .mo files into the database

Translating the theme and plugins using WPML’s String Translation

This option requires WPML’s String Translation module, available as a part of the Multilingual CMS account type.

As we already mentioned, when using String Translation to translate the theme and plugins texts, you can select to load the .mo files as a backup or not.

When loading the .mo file as a backup is selected, WPML will fall back to .mo file translations if those exist in your theme and plugins. This means that if you see a translated text string in your site which does not seem to appear under String Translation, it is very likely that the translation comes from a .mo file in your theme or plugin.

When either of these options is used, WPML scans the theme and finds the texts that can be translated. It reports what it finds and let you enter translations, right from within WordPress.

Since version 3.8 and later, by default, WPML automatically prompts you to scan for new texts in your site whenever a theme or a plugin is activated.

Scanning themes for texts

Scanning themes for strings

You can also manually start the scanning of themes for texts. Select the themes to scan and click on Scan selected themes for strings.  WPML goes through all the files in the selected themes to extract translatable texts from them (texts that are wrapped with gettext functions).

The scanner shows how many strings were found in the theme and their translation status. You can translate them from the WPML -> String Translation page.

In the Localization options section, under Other options, you can find an option to Use theme or plugin text domains when gettext calls do not use a string literal. This option might be helpful if you are using a theme which uses gettext incorrectly.

Scanning plugins for texts

Similarly to scanning a theme for strings, WPML can scan plugins and find translatable strings.

Scanning plugins for texts

Select the plugins to scan and click on Scan selected plugins for strings.

Please note that there is a limitation with scanning the Must Use (MU) plugins. Usually, MUplugins consist of a single file and you can translate them normally. However, if the author has included sub folders which are called from the MU plugin, WPML String Translation cannot access them. This means WPML cannot scan and translate files contained in these sub folders.

Translating the strings

Administrators and Editors can translate theme and plugins texts on the WPML -> String Translation page.

Translating texts via WPML’s String Translation

To translate a text, use the search controls on the top of the page to filter the specific strings. Most importantly, select the domain (it should feature a theme or plugin’s name) whose texts you want to display and translate.

To manually translate listed texts, click the translations link for the text in question, enter the translation, select the Translation is complete checkbox and click Save. If you see translations of the text in question, marked in yellow, this is the translation coming from the theme or plugin’s .mo files. If you prefer, you can override them with your own, by selecting the Use my translation option and providing the translation in question.

You can also assign the selected texts and send them for translation by your designated local translators or professional translation service. For this, you need to have the WPML Translation Management module installed on your site.

Choose the strings to translate, the languages to translate them into and click on the button to Add to translation basket.

Selecting text strings to send to translation

From the Translation Basket tab of the WPML -> Translation Management page, you will then be able to select the translator and send the selected texts for translation.

Your local translators will be able to access the String Translation screen and translate just the ones that you’ve sent them for translation.

Specifying the locales for different languages

A locale is a code which determines which language variant to use for different languages. It is comprised of a combination of language and country.

For example “en_US” means American (USA) English and “en_GB” means English used in the UK.

The locales table in WPML is already pre-populated with the correct values for all popular languages. You should edit it only if you want to use a different language/country combination or if you have added your custom languages. For instance, the default locale for Spanish is “es_ES” (for Spain), but you can change it to Mexican Spanish by setting the Spanish locale to “es_MX”.

To edit the locales, go to the WPML -> Languages page and click the Edit Languages link found in the Site Languages section.

Locale settings

Getting Translation Files for WordPress Itself

In the past, you needed to use the Theme and plugins localization page to download the translations of WordPress core files.

Now, WPML does this automatically any time you add a language on the WPML -> Languages page or during WPML installation.