Jump to content

Invision Community Blog


Managing successful online communities

Mark
Sign in to follow this  
 

IPS 4.0: Internationalization and Localization

One of the things we wanted to focus on for IPS Social Suite 4.0 right from the beginning was providing better support for sites which do not use English or use multiple languages (or, as it was scribbled on my whiteboard, "++ i18n/L19n"). In this blog entry I'm going to cover some of those changes and new features.


Translatable Everything

Currently when you create a forum, user group, custom profile field, etc. you have to give it a title and can only do this in one language. If you have more that one language installed, you might want to provide different titles for different languages.

In 4.0 you can do exactly that - if you have only one language installed, these fields will continue to show as normal text boxes - however, if you have more than one installed you'll see several text boxes like this:



Visual Language Editor

One feature that has been really popular in IP.Board is the Visual Skin Editor - a tool which allows you to browse your site, and click on elements to bring up a colour selector to change it. What if we could take this idea and apply it to translating as well? Allowing you to click on any word or phrase on your site and translate it there immediately. In 4.0, you can.


Easier Language Management

In addition to the visual translation we've also made several improvements to the traditional translation method:

  • As you search for a language string, results appear as you type.
  • Editing a language string saves immediately without needing to click a save button.
  • Filter tabs can show you words/phrases which have not yet been translated or the translation is out of date (meaning we've changed the default English value for the word/phrase since it was translated).

We've also made importing/exporting much faster and more reliable - no matter how large your language is (it will grow as you add more applications of course) there is now no risk of hitting an error importing/exporting (for those interested in the technical side of how this is achieved, see this blog entry).

An exported language pack will also now maintain information on the version of each application it was exported from, so that the filter which shows outdated language strings is always accurate.


Automatic Language Detection

Let's say you have Spanish and French languages installed on your site - up until now, you'd have to choose one default language, and users who want the other would have to manually choose it (which can be extremely difficult to find how to do when you're browsing a site in a foreign language).

In 4.0, we automatically examine the information that the user's browser sends (which includes their preferred language) to choose the best one out of what's available, if that user hasn't already set an explicit preference.

Pluralisation

In English, pluralisation is very simple - for most nouns, you just append "s" on the end, with some variation for certain words.

This however, isn't the case in all languages - for example, I was speaking with the owner of a site in Slovak recently who was telling me that the word "records" changes depending on the number of records there are - for 2 records, it's "2 články", but for 5 records it's "5 článkov". Currently, most language strings only have a singular and plural form (as is all that's needed in English) - meaning having the site show "2 články"/"5 článkov" was impossible.

In 4.0, we've introduced some really basic logic into language strings to accommodate this. Rather than having, for example, two language strings with the singular and the plural, there is now one with a value like this:

{# [1:record][?:records]}


The # indicates where the number will go, then each set of square brackets represents a possible value - the number before the : indicating the number which will cause that to show, and ? meaning "all other numbers".

So for our Slovak example, we'd set the value to:

{# [1:článok][5:článkov][?:články]}


On display, it will automatically show the appropriate version.


Lists

Along a similar thread to pluralisation, we've also made the way lists are formatted to be customised through a special language string. For example, a list in English looks like "one, two and three". However, in Japanese, it's "一、二、三。" (the comma symbol is different and there's no "and") - similarly Arabic, Thai and others have similar differences. In 4.0, simply by changing an example language string, this can be changed.

In the default language, this language string is:

a, b and c


For our Japanese example, we'd just change it to:

a、b、c



UTF-8

Without wanting to get into too much technical detail - UTF-8 is the most common of many ways text can be encoded for storage and display on webpages. UTF-8 has been the default encoding in our software since IP.Board 3.0.

Some sites which have been around for a long while though may not be using UTF-8. This can cause issues with some features where UTF-8 encoding is expected (for example, many features which rely on JavaScript require UTF-8 due to JSON only supporting it and nothing else). In addition, some sites may try to use UTF-8, but content is actually stored differently as the database is set to a different encoding, which can also cause issues.

In 4.0, we're going all UTF-8. If you're not already on it, the upgrader will convert data. This means a much more reliable and compatible way of handling text.

Sign in to follow this  

Comments



Recommended Comments

I wouldn't mind having the ability to have IP.Content pages or databases in multiple languages so I can make my entire site's content multilingual. I use IP.Content to build a website, not a community so it certainly would be helpful but I doubt it'll happen.

 

I cant stress the need for the above enough.! I thought that would be common sense, to have the IP.Content articles in multiple labguages....What if i want to show my users the frontpage of my community in their language. How i will be able to do this?

 

Other than that, fantastic news!

Share this comment


Link to comment
Share on other sites

 

As Mark noted, we are not going to create a situation where every user-provided content is (or can be) provided in multiple languages.  The changes outlined apply to admin-defined text, not user-supplied text.

 

I am unsure what you mean about having "a forum subject covered by a forum for each language" exactly.  You can still create multiple forums for each subject (one per-language) if you prefer.  Or you can have one forum and specify the forum title for each language individually.  That will be up to you.

Sure, but how do you connect these forums? As the only difference between these forums is the language, surely they should be connected.

The same goes for articles in the CMS. If you write an article in English, but you also have a French section, then it should be possible for members to translate the article and post it as a translation. This means that readers will have to be able to find the French translation when looking at the English article. Its a basic CMS function.

Share this comment


Link to comment
Share on other sites

This is great stuff--I have a ton of European users and would love to have translations for a few different languages (such as German, Polish, French, etc.)  I'm sure I can get help from my users translating forum-specific text.  :)

Share this comment


Link to comment
Share on other sites

I should preface this by saying that we will adapt the translation capabilities as needed to accommodate everyone's needs to the extent feasible.  What you see in this blog entry shouldn't be construed to be the final result with no further changes possible.

 

bfarber maybe some user of this forum did not understand that there will be multilingual forum, but the forum will always have the language defined by each individual user, am I wrong? I understand you correctly?

 

I'm afraid I still don't really understand.

 

If you have French and English language packs installed, then when you specify the forum name you define the name in both French and English.  If a user is using the French language pack they see the French forum name, and vice-versa.  Any user-defined text (as in, not defined by the admin) is in one language.

 

 

 

I'm sorry, but it looks like you are misunderstood my question. I'll try to explain it in more detail.
 
So, for example i have 1 forum with 3 names in 3 different languages.
 
And we have some topics in all that languages collected in this one forum.
 
If user will be able to specify his language in the editor(when he starts a new topic), we will get one more field for filters and sorting. Then all other users will able to show/hide only topics with a specific language (or not indicated).
 
Sorry for my English.

 

 

Topics are user-supplied and subsequently are not provided in multiple languages or tagged to a single language, so I don't see how there would be a possibility for a language filter in the example you provide.  The forum may be translated into 3 languages (if you have done so), but the topics within it are still just one language each.

 

I believe I understand what you are suggesting (tag topics and other user submitted content by a language and then only show that to people using the same language), but personally I feel like that would be bad for content discovery.  What if my preferred language is English but I can speak French just fine (or at least read it and understand)?  Suddenly any topic that is in French I no longer see unless I specifically filter for it, or change my language back and forth on the board?

 

 

:blink: ...

 

And the what text will be used?

 

For user-supplied content (i.e. topics) this is not relevant.  For forums or category names (admin defined text), the default language.

 

You cannot have multiple different URLs pointing to the same content.  This is like rule #1 for bad SEO.

 

 

Sure, but how do you connect these forums? As the only difference between these forums is the language, surely they should be connected.

The same goes for articles in the CMS. If you write an article in English, but you also have a French section, then it should be possible for members to translate the article and post it as a translation. This means that readers will have to be able to find the French translation when looking at the English article. Its a basic CMS function.

 

IP.Content isn't finished, and as much of its text is supplied in the ACP, we may implement translating capabilities there.  It is still unlikely that any user-supplied textual areas (posts in a topic, for instance) will have translation capabilities, nor is it likely that we would allow users to translate existing content (i.e. letting a French user translate an admin-supplied article via the front end).

Share this comment


Link to comment
Share on other sites

It is still unlikely that any user-supplied textual areas (posts in a topic, for instance) will have translation capabilities, nor is it likely that we would allow users to translate existing content (i.e. letting a French user translate an admin-supplied article via the front end).

That's fine. What I'm looking for is the ability to have pages (completely admin defined) in multiple languages. Articles and databases too if possible, but start with pages.

 

Btw, are pages like the board guidelines and privacy policy going to be in multiple languages?

Share this comment


Link to comment
Share on other sites

I believe I understand what you are suggesting (tag topics and other user submitted content by a language and then only show that to people using the same language), but personally I feel like that would be bad for content discovery.  What if my preferred language is English but I can speak French just fine (or at least read it and understand)?  Suddenly any topic that is in French I no longer see unless I specifically filter for it, or change my language back and forth on the board?

Yes, you understand correctly. But filters can be turned off by default and turned on if it's needed. Example:

 

image.png

 

For forums or category names (admin defined text), the default language.
 
You cannot have multiple different URLs pointing to the same content.  This is like rule #1 for bad SEO.

Yes! That's what I'm asking. The previous answer was different and very confused me :)

Share this comment


Link to comment
Share on other sites

Make every language string assigned to the particular one addon only.

Make every addon language pack file(s) export/import completely independent in the system from each other (on the per addon basis).

Share this comment


Link to comment
Share on other sites

Will there be a way to have certain special characters with diacritical marks in the customizable rich editor? 

 

Some of the German ones like ä  ö  ü  ß are problematic to type in Chrome since they involve combinations of alt+4 which wreak havoc. Will we be able to macro some of those in? maybe?

Share this comment


Link to comment
Share on other sites

I have a question: into template you have used {utf8_encode(language_bit_string)} where there are title='...' ?? Because apostrofe destruct elements into template 3.x

Only using this charsets is converted into iso-8859-1 (standard for charset) (you use utf8 because system use json encode)

Share this comment


Link to comment
Share on other sites

From scratch. The language pack will be so different, it really isn't worth it.
 
Not presently, though if this is a requirement in a particular language, we can change it.
 
It looks like your constructive alternative suggestion after your pointless sarcastic comment got cut off, could you post it again?
 
We haven't quite fleshed out the details but yes.

but for furl is possible apply this new format?
example I have a forum italian but some user are english and default (for crawler etc..) I would setted italian language but I would leave to user a choise to set apply english or other language installed (that I choise if for each is setted a change of furl such as this method)

Share this comment


Link to comment
Share on other sites

 

Translatable Everything
 
Currently when you create a forum, user group, custom profile field, etc. you have to give it a title and can only do this in one language. If you have more that one language installed, you might want to provide different titles for different languages.
 
In 4.0 you can do exactly that - if you have only one language installed, these fields will continue to show as normal text boxes - however, if you have more than one installed you'll see several text boxes like this:
blogentry-108264-0-77513200-1372861493_t

but each key will exported into custom language pack? or that will saved into database sql only?

thanks for attention

	public function form( &$form )
	{
		$form->add( new IPSHelpersFormTranslatable( 'pfield_group_title', NULL, TRUE, array( 'app' => 'core', 'key' => ( $this->id ? "core_pfieldgroups_{$this->id}" : NULL ) ) ) );
	}

Share this comment


Link to comment
Share on other sites

Have you planned a system that allows members to send their message in a language and those who have chosen this language means that the comments of this language and not mix like now?

Share this comment


Link to comment
Share on other sites

Does the change allow me to translate/customize the navigation tabs and hoover tooltips as well (forum, members, calendar, gallery, downloads, etc.)? The last time I tried this, the system wasn't flexible enough to allow for different translations per tab/hoover tooltip due to them using sharing parts of the text strings, so I ended up with some strings that sounded a bit strange.

 

This would benefit english users as well, as you would be able to replace the generic and unhelpfull tooltip  'Go to <AppName>' with a better text such as 'View a list of members', 'Open the gallery', 'Access downloads', etc.

Share this comment


Link to comment
Share on other sites

{# [1lánok][5lánkov][?:články]}

 

This will not work for the Russian language. 

 

For example, you have 368 downloads and 123456 vies of something. 

 

In this case, you will have to translate 1,2,3,4,5,6,7,8,9,10 views and downloads into Russian and then repeat translation according to the last digit in the number of views or downloads.

Share this comment


Link to comment
Share on other sites

Example as it should work (view - просмотр):

{# [1:просмотр][2:просмотра][3:просмотра][4:просмотра][5:просмотров][6:просмотров][7:просмотров][8:просмотров][9:просмотров][10:просмотров]}

Example as it should work (download - скачивание):

{# [1:скачивание][2:скачивания][3:скачивания][4:скачивания][5:скачиваний][6:скачиваний][7:скачиваний][8:скачиваний][9:скачиваний][10:скачиваний]}

So, for 368 downloads it should be as for 8 downloads: [8:скачиваний], and for 381 downloads it should be as for 1 download: [1:скачивание]. But this is not possible I think in the present system of translation. That means that everything will be translated as it was in 3.4.x.

Share this comment


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...