Versions Compared

Old Version 9

changes.mady.by.user Perry Tew

Saved on

compared with

New Version Current

changes.mady.by.user Jonathan Tew

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Static Text

When calling static text in the content of your storefront pages. If the template contains a call to the $i18n.write, then its performing a look up first against the languages file "eng.default.json" for a match.

If it finds a match there it will use the text as defined in the languages document.  If it does not find a match there, it will use the string as defined in the template code directly.

Example

...

Include Page
Theme Multi-Lingual Support
Theme Multi-Lingual Support

 

Directions for editing a language file

Include Page
Changing Checkout Text
Changing Checkout Text

Static Text

If you edit a template you may be tempted to just place static text into the template.  For example you are putting in a title div into the document like this:

<div class="ucColorSubHeader">Your contact email</div>

If you enter text directly like this into the template, it will generate an i18n (internationalization) violation.  An i18n violation means there is a piece of text that the system can not automatically translate when the customer is browsing in a different language.  To get around this problem, the text is passed through the i18n system so that it can be tracked and translated.  To do this, use the $i18n object by calling $i18n.write like the example below.

<div class="ucColorSubHeader">$i18n.write("checkout.viewcart.yourContactEmailField", "Your contact email")</div>

Notice that there are two parameters on this $i18n.write call.  The first parameter is a "key" and then the second parameter is the text.  Every single write call needs to have a unique key associated with it.  The key is arbitrary, but you will typically see a three part key used by our theme developers: section.template.textIdentifier.

Advanced Static Text - lang attribute

Part of the agreement when performing automated translation is that a lang attribute will be added to the containing element to tell the search engine how the content was translated.  We try to make this as easy as possible.  Let's take the example above for the text "Your contact email"

<div class="ucColorSubHeader">$i18n.write("checkout.viewcart.yourContactEmailField",

...

 "Your

...

contact

...

email")</div>

This can be transformed into the following code:

<div class="ucColorSubHeader" 

Muti-lingual Support

Warning

StoreFronts does not yet support multi-lingual pages. You may switch the language in your merchant settings, but we do not yet have on-the-fly support for browser language headers.

 

Directions for editing a language file

Include PageChanging Checkout TextChanging Checkout Text$!{i18n.htmlLang("checkout.viewcart.yourContactEmailField")}>${i18n.write("Your contact email")}</div>

There are a couple of important things to point out about this coding change.  First off the call to htmlLang will produce a complete lang attribute tag for the element if necessary.  If not it will produce nothing.  The exclamation point after the dollar sign in that call instructs Velocity to output nothing if the result of the function call is null.  It is best practice to include that in the call.  The second thing to notice is that the write call now has a single parameter which is the default text.  When write is called with a single parameter, it knows to use the key from the previous htmlLang function call.  This shortens the amount of code that has to go into the template in order to achieve compliant HTML translation capabilities.