Jump to content

Suggestion: Multilingual improvements


Califpornia

Recommended Posts

Hi. Now it's not so easy to manage site with more than one language, when it comes to localizing applications. Or updating apps and their locales.

Now if i import language XML, it will be written into all languages, so i forced to use separate forum for language updating.

Why not just allow us to select which language to load this .xml into?

Second trouble is for app developers. Now you can distribute only one language with your app. You can separately release other languages, but your users will face trouble, described before.

I think if all locales will have global locale id (like ru_RU for Russian), and we can write multiple locale variants in our apps, it will be easer to share your app with users of different languages.

Link to comment
Share on other sites

I am currently working on a site for a client. Localization is absolutely necessary. I was certain that IPB was able to do this easily, having language XML files. Suddenly I'm realizing that virtually all sites don't have any localization options, It's one language only. This is not a viable solution. In fact, in some countries and areas it is law that you provide at least two language options. In the US, Spanish is rapidly becoming a need to know language. So I'm wondering if anyone has tackled the localization issue. Ironic to find this post just when I was dealing with the same thing.

Link to comment
Share on other sites

Hi. Now it's not so easy to manage site with more than one language, when it comes to localizing applications. Or updating apps and their locales.
Now if i import language XML, it will be written into all languages, so i forced to use separate forum for language updating.
Why not just allow us to select which language to load this .xml into?

Second trouble is for app developers. Now you can distribute only one language with your app. You can separately release other languages, but your users will face trouble, described before.
I think if all locales will have global locale id (like ru_RU for Russian), and we can write multiple locale variants in our apps, it will be easer to share your app with users of different languages.


I reported this on IP.Board 3.0.0 and reply to all topics like that. Who knows we can wait this for IP.Board 4.0.
Link to comment
Share on other sites

I reported this on IP.Board 3.0.0 and reply to all topics like that. Who knows we can wait this for IP.Board 4.0.

No can do. Believe it or not, it's a legal problem for several of my clients. It's either at least two languages for localization or we're going with another publishing and forum platform and not turning back.

I'd consider paying a developer to help me solve this problem in a reasonable manner. The question is whether there is a feasible way of handling this. This is a big concern.

Link to comment
Share on other sites

Not without a huge change on all manage language system.

Why is this the case? There are multiple XML files in the Localization Manager. Perhaps I assumed the obvious that you could pull either one and perhaps have it set by user as to which one to use. What is the impediment? (unfortunately, you're one of the people I would expect to know a great deal about how things work under the hood.) I'm now apprehensive that what you're going to tell me is that it relates to the manner in which IPB 3.4.1 is coded, e.g. you'd have to have the language variable that is set globally to apply to all users and that it would need to be reset each call to the database satisfy that user's language requirement as opposed to it being an attribute of the user class.

Link to comment
Share on other sites

Also i have idea. [locale=en_US] tag (or similar one). With it we can filter our news posts content to separate different languages in one post, so user will see only selected locale's part of post.

Example:

[locale=ru_RU]Текст на русском[/locale]
[locale=pt_BR]Texto em Português[/locale]
[locale=default]Text in English[/locale]

So if user will select any language that is not listed in post, it will see English version (as a default locale), but if Russian language selected, then user will see first part of post.

Of course it will require some changes to localization system like in my first post of this thread (system should know if 'My language' is English, or other)

Link to comment
Share on other sites

In theory it's very simple. But as of yet I don't know how IPB works under the hood with the exception of simple hooks, template and css modifications. I can only hope that there is some ability for the software to recognize client side requests as you suggest. Then there is also the issue of how language is handled on the server end. I'd like to get an answer for this and hopefully find some type of solution, even if some of it is just temporary.

I had thought of creating a second skin and editing out the relevant variables and hard coding them. That will still leave quite a mess as much is dynamically generated so that was out. Then I was tinkering with the idea of running two sites on one domain, e.g. p.mysite.com for a polish language. This came as quite a surprise as every script I know has some solution or an option to use replacement variables which gives you a second language.

Link to comment
Share on other sites

Being able to fully localize a site and the original post are actually two different issues. In the original post, he's pointing out if you import just a Russian IP.Downloads language file (for instance), it updates even the English pack, because our language system treats a single application import different than a full language pack import.

Being able to localize all areas of the software (save for content actually submitted by users) would be a big change in how IP.Board works. You can localize all textual data that we utilize throughout the software, except for data that you can supply via the ACP and which is stored in a database, and therein lies the issue. We store a forum name (for instance) in a database column with the forum data. There is no way at present to then translate this per-language. It is something we are discussing for 4.0, but there is no immediate solution for 3.4 outside of modifying your templates.

Link to comment
Share on other sites

Being able to localize all areas of the software (save for content actually submitted by users) would be a big change in how IP.Board works. You can localize all textual data that we utilize throughout the software, except for data that you can supply via the ACP and which is stored in a database, and therein lies the issue. We store a forum name (for instance) in a database column with the forum data. There is no way at present to then translate this per-language. It is something we are discussing for 4.0, but there is no immediate solution for 3.4 outside of modifying your templates.

Brandon, many thanks for the reply and the time to explain how it all works.

I'd truly appreciate knowing how one can go about solving the issue of how to have the language set for all the textual data stored throughout the software on a per user basis. That would at least get us a reasonable part of the way there and we can figure out the rest as we move along.

The problem isn't even really the forum name - that's almost the same as user submitted data and not subject to being localized. For example, we'd input a forum in Italian and all the messages would be in Italian. The problem are fields entered into the ACP or built in such as the member profile attribute names, e.g. Gender, Location. They are output as part of an array of data being pushed to the browser and not the XML language files.

Brandon... I really, really don't want to put these clients on PHPBB!!!! (w00t)

Link to comment
Share on other sites

What you would have to do is something like editing the template to use

$this->lang->words['localized_somethinghere_' . $this->member->language_id ]

And then add localized_somethinghere_(langids) to your language files. "somethinghere" would be a key you make up for each string you want to translate, and you'd then insert one entry for each language, swapping out langids appropriately.

Link to comment
Share on other sites

Thanks for replies!

Maybe it's because of my poor English, so i can't fully describe my ideas :)

I know there is some limitations with user-posted contents, and it's OK. I just wanted to know if you have plans to change the way language system works (import/export problem).

Well, idea with locale tags is just bonus :)

Link to comment
Share on other sites

Personally I would say that for us this sounds like a waste of server resources and energy.

While I do understand someone would like to localize in every way imaginable it shouldn't come at the cost of being required to provide alternate translations of forum names or causing the server to use more time generating the output.

If something like this is added to translate forum descriptions, names etc. it should be highly optional. Creating forums should work the same way as before by default.

Just my five cents.
(Click to display new editor rant caused by this post bugging out before I fixed it)

Link to comment
Share on other sites

Personally I would say that for us this sounds like a waste of server resources and energy.

While I do understand someone would like to localize in every way imaginable it shouldn't come at the cost of being required to provide alternate translations of forum names or causing the server to use more time generating the output.

If something like this is added to translate forum descriptions, names etc. it should be highly optional. Creating forums should work the same way as before by default.

Just my five cents.
(Click to display new editor rant caused by this post bugging out before I fixed it)

Indeed, the VAST VAST majority of our users only support one language on their site (whether that is English or otherwise is irrelevant). Any changes here would absolutely need to be optional and only geared at sites that have a need for multilingual support.

Link to comment
Share on other sites

Personally I would say that for us this sounds like a waste of server resources and energy.

While I do understand someone would like to localize in every way imaginable it shouldn't come at the cost of being required to provide alternate translations of forum names or causing the server to use more time generating the output.

If something like this is added to translate forum descriptions, names etc. it should be highly optional. Creating forums should work the same way as before by default.

Just my five cents.
(Click to display new editor rant caused by this post bugging out before I fixed it)

To some degree I don't disagree with you. Most sites are single language based because mix and match doesn't work so well.

The problem is bilingual is becoming very common now in many areas. Having the ability to provide two languages with the same software is key, e.g. one IPC database for Spanish and one for English - but using the same site to provide the services. Not the end of the world but in some countries, such as where I working with a client now, bilingual is required. No way around it. Do I think this is a feature that comes at great expense - no. But if we're thinking about restructuring the architecture, I'd say this should be right in the front of that discussion in the planning phase.

Link to comment
Share on other sites

Hi again.

I've found very simply solution for XML importing issue. And it's very quick!

All you need to do is replace/add couple of strings in two files. If this fix will be accepted by developers, it will require adding of two localization strings also.

I hope i will not break any forum rules by posting simple find-replace 'patch' here.

So, what i ended with:

1. Open admin/applications/core/modules_admin/languages/manage_languages.php

2. Find:

		//-----------------------------------------
		// We need to add language bits to every pack..
		//-----------------------------------------
		
		$this->DB->build( array( 'select' => 'lang_id', 'from' => 'core_sys_lang' ) );
		$this->DB->execute();
		
		while( $r = $this->DB->fetch() )
		{
			$lang_ids[]	= $r['lang_id'];
		}

3. Replace with:

		if ($lang_id > 0)
		{
			$lang_ids[] = $lang_id;
		}
		else
		{
			//-----------------------------------------
			// We need to add language bits to every pack..
			//-----------------------------------------
			$this->DB->build( array( 'select' => 'lang_id', 'from' => 'core_sys_lang' ) );
			$this->DB->execute();
			
			while( $r = $this->DB->fetch() )
			{
				$lang_ids[]	= $r['lang_id'];
			}
		}

4. Open admin/applications/core/skin_cp/cp_skin_system.php

5. Find

        <tr>
            <td class='field_title'><strong class='title'>{$this->lang->words['sys_or_enter_the_filename_of_the_x']}</strong></td>
            <td class='field_field'><input class='textinput' type='text' size='30' name='file_location' /><br /><span class='desctext'>{$this->lang->words['sys_the_file_must_be_uploaded_into']}</span></td>
        </tr>

6. Add after:

        <tr>
            <td class='field_title'><strong class='title'>[NTL]Import data from XML into</strong></td>
            <td class='field_field'><select name='id'><option value='' SELECTED>[NTL]All languages</option>
HTML;
foreach( $rows as $r )
{
    $HTML .= "<option value='{$r['id']}'>{$r['title']}</option>n";
}

$HTML .= <<<HTML
				</select></td>
        </tr>

Done! Next time when you upload XML file without language pack info, you'll able to select which language import strings to.

There is two strings with [NTL] (need to localize) prefix, it should be added into relative language pack.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...