Turn Osclass into SINGLE item description keeping your site Multi-Language

[SmaRTeY]

Hi,

since I "WANT" my system to offer my users a multi-language system but NOT posting ads in a language different than my standard language as configurated in Admin, I have made changes that enable me to have my wish without any related issues so far...

To achieve this I used three 'tweaks' created by teseo and two core changes by myself:

Pre-requisites:
1) Make sure you have more than one language installed and set active for the website!
2) Set the default site language once, do not change it afterwards because this IS the language used from now.
3) Make sure your existing ads, if any, are ALL using the default/standard locale:
- You need to update existing item-description-locale for this using phpMyAdmin!!
- You need to delete all item descriptions except those with the default language locale as mentioned in 2.

Steps:
1) Let your system only publish ads in default language no matter the current user locale:
http://forums.osclass.org/general-help/how-to-remove-multiple-languages-in-post-page-only-not-whole-website/

In the above link/thread the sample code from teseo uses the "osc_current_user_locale()", to make the system use ONE default language independent from user chosen language I use the default Osclass language.
To achieve this make sure you change: <?php $current_locale = osc_current_user_locale(); ?> into <?php $current_locale = osc_get_preference('language'); ?>
This is a theme 'fix', by using the default locale in both item-post.php and item-edit.php all ads will be posted in your default language as setup in Admin.

2) Always show the search result with keyword search no matter what current user locale was used when saving the ad:
http://forums.osclass.org/3-5-x/search-problem-oc-3-5-3/msg122409/#msg122409

By simply adding this code in your themes folder's functions.php the search result will always be shown no matter what current locale is:

Code: [Select]

function AddSearchConditions() {

if (isset($params['sPattern'])) {
$mSearch =  Search::newInstance();
// To enable locale independent search we Add a wildcar for locales with Pattern search
$mSearch->addLocale('%');
}

}
//Add our new search condition to the search conditions used by Osclass
osc_add_hook('search_conditions', 'AddSearchConditions');

3) Change core file "user.php" in folder: /oc-includes/osclass/controller/ to enable Alerts no matter what current locale is used.

Add/insert the following code that makes locale = all locales after line 89:

Code: [Select]

$search->addLocale('%');
4) Make sure categories are translated correctly when switching language on website while being on search result page. Thanks to teseo's help the following functions fix an issue with translation related to url change. Place the following two functions in your theme's "functions.php" :

Code: [Select]

// Two custom functions used to make search-category-result language switch work as long as core is not fixed!
// Credits go to teseo
// Theme needs following change:
// You need to replace in your theme "osc_change_language_url" with the other new function, "cust_change_language_url".
function cust_change_language_url($locale) {
    $url = osc_change_language_url($locale);
    if( osc_rewrite_enabled() && osc_is_search_page() ) {
        $cats = osc_search_category();
if(isset($cats[0])) {
return $url . '/?category=' . $cats[0];
}
    }
    return $url;
}

function cust_on_change_language_translate_categories() {
    $params = Params::getParamsAsArray();
if(isset($params['page']) && isset($params['category'])) {
if ($params['page'] == 'language' && $params['category']) {
$translateCat = new DAO();
$translateCat->dao->select('s_slug');
$translateCat->dao->from(DB_TABLE_PREFIX.'t_category_description d');
$translateCat->dao->join(sprintf("(SELECT fk_i_category_id
FROM %st_category_description
WHERE s_slug = '%s') id", DB_TABLE_PREFIX, $params['category']), "d.fk_i_category_id = id.fk_i_category_id", "INNER");
$translateCat->dao->where(sprintf("d.fk_c_locale_code = '%s'", $params['locale']));
$result = $translateCat->dao->get();
$result = $result->row();

if ($result) $_SERVER['HTTP_REFERER'] = str_replace($params['category'], $result['s_slug'], $_SERVER['HTTP_REFERER']);
}
}
}
osc_add_hook('init', 'cust_on_change_language_translate_categories');
Make sure you also check your theme and change the "osc_change_language_url" into the new function name!

5) Update another function in /oc-includes/osclass/model/Item.php called "extendDataSingle($item)" which is used to get item descriptions
based on current user locale. Without this change you risk getting -empty- item descriptions when code is used to get data through "Item class" directly.
       
Change the line: $prefLocale = osc_current_user_locale(); into $prefLocale = osc_get_preference('language');
         

That's it, new ads will only get published in default locale.
Searches are always done using *all* locales so they will show up in search results no matter what locale is "current"
When on Search result page you are able to change site language without issue!
Item descriptions will always be fetched based on default locale
Alerts will always show the items no matter what locale is "current"


NB1. This is a HACK so no guarantees and IF you want to use it you do so at own risk.
NB2. Be sure to make backup before making any changes!

I am using it on my own site and so far everything seems to work 100%.


Regards,
Eric

[SmaRTeY]

This topic need an update with the Upgrade of Osclass from 3.5.7 to 3.5.9.
Due to the fact that Osclass uses the Params::getServerParam('HTTP_REFERER') instead of direct use of $_SERVER(HTTP_REFERER) as it did before we now need to create a 'fix' that will prevent the breaking of the code when switching language using a search/category result URL.

Now, the main cause of breaking code in 3.5.9 is in the file /oc-includes/osclass/controller/language.php
Since the Params class is used now to get the HTTP_REFERER (which is a good thing) we need a new way to manipulate the HTTP_REFERER as is done in our 'Hack' to make language switching with category in search result url work correctly.
However, I could not find a way using current code to change (only) the HTTP_REFERER using the Params class. I tried to use the 'init' function which does have an effect but not the desired result we need. So to keep this working I created a new small function in the class /oc-includes/osclass/core/Params.php called 'reset_referrer' and it looks like this:

Code: [Select]

//Created to simply be able to re-set the $_server var when switching language
static function reset_server() {
self::$_server = $_SERVER;
}

You can put this function below the 'init' function of the class Params.

Now in your themes functions.php you need to replace the following function 'cust_on_change_language_translate_categories' with the one below:

Code: [Select]

function cust_on_change_language_translate_categories() {
    $params = Params::getParamsAsArray();
if(isset($params['page']) && isset($params['category'])) {
if ($params['page'] == 'language' && $params['category']) {
$translateCat = new DAO();
$translateCat->dao->select('s_slug');
$translateCat->dao->from(DB_TABLE_PREFIX.'t_category_description d');
$translateCat->dao->join(sprintf("(SELECT fk_i_category_id
FROM %st_category_description
WHERE s_slug = '%s') id", DB_TABLE_PREFIX, $params['category']), "d.fk_i_category_id = id.fk_i_category_id", "INNER");
$translateCat->dao->where(sprintf("d.fk_c_locale_code = '%s'", $params['locale']));
$result = $translateCat->dao->get();
$result = $result->row();
if(isset($_SERVER['HTTP_REFERER']) && $result) {
$_SERVER['HTTP_REFERER'] = str_replace($params['category'], $result['s_slug'], $_SERVER['HTTP_REFERER']);
//We call a new defined function that enables us to re-set the 'serverparameter' variable $_Server
Params::reset_server();
}
}
}
}

That's it! Now this hack will keep working with Osclass version 3.5.9.
In case someone has a better solution please let us know, for now this works but let's be honest, Osclass should simply have a working mechanism that enables us to switch languages without getting 404's so hopefully soon a version that incorporates similar code that does just that.


Regards,
Eric

[dev101]

Hi Eric,

you can use Params::getServerParam('HTTP_REFERER', false, false) instead.

Regards,
dev101

[SmaRTeY]

Hi dev101,

That is what is implemented in latest version and only 'reads' the current HTTP_REFERER value as where we need to UPDATE the HTTP_REFERER in runtime for category names to be translated correctly in url's when switching languages.

It is due to this Params implementation that the original 'fix' was no longer working.

Hi Eric,

you can use Params::getServerParam('HTTP_REFERER', false, false) instead.

Regards,
dev101

[dev101]

Thanks, got it, sorry haven't really tested your mod and thought something else was the issue.

Regards
dev101

[SmaRTeY]

No problem.

Actually the mod is part hack and part fix with regard to switching language when viewing search result page which includes a category name.
If you select a category and do a search all goes well but then viewing the search result try changing the language.
With current Osclass version (and previous versions) that language change will result in a 404 error.
The mod below makes the language switch work without issues and it could/should be somehow incorporated in Osclass imo

[dev101]

That bug was fixed in 3.5.9.

I was testing early implementation few weeks ago and found some bugs, but this was a leftover later discovered here in forums.

[SmaRTeY]

No that bug is still here and there is a fix created by teseo which I am using to my satisfaction

That bug was fixed in 3.5.9.

I was testing early implementation few weeks ago and found some bugs, but this was a leftover later discovered here in forums.

[dev101]

Hi SmaRTeY,

1) my post above when I said 'leftover' was referring to this bug here, while you were referring to something different (and much older).

2) I thought that I have shown you via pm that it works for me in default version? I am glad that teseo's fix worked for you, but I could not reproduce that error in recent versions, as shown and as we already discussed.

Hope this makes it more clear on which/what/where
But nevermind, as long as it works it's good

Regards
dev101

[SmaRTeY]

Hi dev101,

true but I find it hard to believe that the issue which gets fixed by teseo's fix is not a code issue but some other server/setup issue.
I did see it work in your demo but I was unable to see your (language) setup in Admin, maybe I should have a look and see if I can make some Admin changes that make the issue on your demo site?

If I can't reproduce on your site I will swallow my words and accept het issue must be something server/setup related

[dev101]

Well, could be, this needs a proper investigation, I agree

I am not really sure what is the cause of it (e.g. why you have it, I do not - and not on one, but 2 completely different systems). My language setup was just plain default (all l's enabled, nothing changed by myself - never really go to that page on test setups). In any case, it is good that at least a solution/fix exist.

[SmaRTeY]

Cool, let's see if I can show you what causes the issue.
We'll discuss it in PM and share the outcome here again?

Well, could be, this needs a proper investigation, I agree

I am not really sure what is the cause of it (e.g. why you have it, I do not - and not on one, but 2 completely different systems). My language setup was just plain default (all l's enabled, nothing changed by myself - never really go to that page on test setups). In any case, it is good that at least a solution/fix exist.

[dev101]

Fine, but here's what you should do: create a 'standard' environment (same one as 10 days ago), forget about your exotic stuff and we'll see then if the issue remains.

But, from my experience with this kind of funny things that you have no idea where are they coming from, is that even changing server environment under visualization is not enough, because the bug might be caused in a higher level that controls it.

What I am trying to say is that to resolve such an issue you need to change a hosting provider, and test it on a different system entirely, to draw meaningful conclusions.

[seti]

Hi,

Wouldn't it be simpler if osclass just added A third column in the language cpannel setting for Enabled (Publish Ad), instead of just the two default options, Enabled (website), Enabled (oc-admin). That way you can turn off the languages you don't want users to use when publishing ads...

[dev101]

Great suggestion, seti

Something core team should think about, definitely.