Skip to content

Conversation

@teseo-2014
Copy link

These modifications affecting listWhere() and listEnabled() functions allow full translation of Categories names depending on User selected language, with fallback to Default site language and the rest of enabled languages (in this order) in case there were no translated Category name for User selected language.

The resultant queries are just a bit more expensive than current ones (that are failing to translate properly), but anyway they are cacheable by MySQL.

These modifications affecting listWhere() and listEnabled() functions allow full translation of Categories names depending on User selected language, with fallback to Default site language and the rest of enabled languages (in this order) in case there were no translated Category name for User selected language.

The resultant queries are just a bit more expensive than current ones (that are failing to translate properly), but anyway they are cacheable by MySQL.
@conejoninja
Copy link
Member

Hi, could you tell us some examples of when the translation of categories are failing?

@teseo-2014
Copy link
Author

Hi,

As far as I can see, they are being translated only in Premiums loop of search pages, please see here:

http://li266-32.members.linode.com/show/353-vanilla

(Default language: Spanish, but you can choose between four languages)

Same installation with modded Category.php:

http://li266-32.members.linode.com/353-modded

A discussion about this issue:

http://forums.osclass.org/3-5-x/pb-osclass-update-to-3-5-2-with-osc_category_name()

Regards

- Detected a problem when default English language has been disabled on the frontside. Now "en_US" is always added to the query to solve that. Also, possible unknown remaining records on t_category_description table for disabled languages are expressly excluded (same case that the problem with disabled English).

- To avoid duplication of code for building the locales list for the queries produced by listWhere and listEnabled functions, I've added a new property _localesList.
@teseo-2014
Copy link
Author

Hi,

I have made modifications to address this:

  • Detected a problem when default English language has been disabled on the frontside. Now "en_US" is always added to the query to solve that. Also, possible unknown remaining records on t_category_description table for disabled languages are expressly excluded (same case that the problem with disabled English).
  • To avoid duplication of code for building the locale list for the queries produced by listWhere and listEnabled functions, I've added a new property _localesList.

Sorry is something is wrong with the commit and such, still a complete noob on this GitHub thing. :D

@dev-101
Copy link
Contributor

dev-101 commented Oct 26, 2015

Just had a long discussion with SmaRTeY from forums, strange that on his server he had this problem, and on mine everything works fine. Both versions were clean 3.5.9 with same dutch and english languages installed, yet on his server changing the languages did not translated categories into dutch (they were left in english).

Then I recalled this and suggested to try teseo's fix and it worked right away.

Bottom line, since the "only" difference is the server configuration and environment itself, we could not really say what is the exact cause of such behavior. Nothing in the logs could indicate the issue.

Patch over Osclass 3.5.9 version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants