#33306 – Language versions of the interface messages

Posted in ‘Akeeba Ticket System’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Wednesday, 24 June 2020 10:07 CDT
yvesfb

Hello,

I have a multi-lingual website.

1°) I would like that the users see all the linguistic posts whatever their language (so to set the categories to ALL), but I would like that the title and the description of the categories are published in the language the user is working with. 

I tried to use specific text string and then to use the language override, but it doesn't work.

Any possible way to adapt those descriptions?

 

2°) in case I use this "ALL" configuration for the categories of the tickets, does the user receives the emails/notification in his/her working language (the language he/she was using when posting the ticket)? or is it then the default language of the website? or the language preference of his/her profile?

 

Regards

yves

Custom Fields

Joomla! version (in x.y.z format) 3.9.19
PHP version (in x.y.z format) 7.2.31
Akeeba Ticket System version (x.y.z format) 3.4.1
 
Wednesday, 24 June 2020 10:21 CDT
nicholas

1. No, you cannot do that. That's not how Joomla's multi-language feature works. You can have one language per category or have a category that's displayed in all languages. In the latter case the title and description is common for everyone. Frankly, the "All" language option is made for use by single-language sites.

What you are looking for seems to be a translated site, not a multi-language site. This is not possible with the Joomla core. There are third party extensions, like Falang, but please bear in mind that we do not support them.

2. Emails are sent in the user's preferred language per their user profile. If it's not set or an email template is not set up for this language, emails are sent in the site's default language. If that's not set or an email template is not set up for this language either we fall back to English (Great Britain). Finally, if all else fails, we will use the All language email template.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Wednesday, 24 June 2020 11:13 CDT
yvesfb

Thank you Nicholas for your feedback.

I have been able to use then the extension "conditional content" of Regularlabs in the title and in the description of a category with conditions on the language code (and defining the ATS categories at "ALL" so that the users can find all th posts related into one category and still use their natural language interface. 

It doesn't look that tidy in the backend when you list de categories, but it works so far.

If you make developments in that direction in the future, it would be great being able to associate categories across languages if possible, and to have the possibility to list all the tickets , whatever their language, into the page visited by the user. (not to translate the content of the tickets, only to list them).

yves

 
Thursday, 25 June 2020 00:54 CDT
nicholas

If you make developments in that direction in the future, it would be great being able to associate categories across languages if possible, and to have the possibility to list all the tickets , whatever their language, into the page visited by the user. (not to translate the content of the tickets, only to list them).

There are two mutually exclusive ideas in there, neither of which would work for your.

Idea 1: Language associations. This is how Joomla does it for articles, menu items etc. We are not going to implement this. This can already be done with a hidden menu and menu item associations. Since this is a very standard method for building Joomla sites we don't even need to document it.

Idea 2: Display items from multiple categories on a single category's page. This is not going to happen EVER. It is a horrible idea on UX, performance, security and architectural level.

The performance is abysmal. Searching for a single category is an optimal operation for MySQL. It uses an index in a way that makes it super fast. Start adding categories and things gets wonky. In some queries it will not even use the index because it determines it's faster to just go through the entire dataset.

From a UX perspective this idea is a mess.  No pagination, no searching, no filtering by status, no SEF URLs, no New Ticket button and the list goes on.

Each category has its own view level and permissions. Trying to merge them creates a major issue. What is the effective view level and permissions of the union? There is no universal way to determine that. Any implementation will lead to several cases where people see content they shouldn't or are able to file or administer tickets when they shouldn't. It's conceivable that because of the complexity of the code this would introduce a vulnerability which would allow an attacker to covertly exfiltrate private information.

As for architecture, this adds a level of complexity that permeates the entire component. For marginal gains we are introducing a slew of conditionals and ungodly tricks which will make the code far harder to maintain and introduce bugs.

In so many words, no, I am not going to do it. I know better than to make this kind of colossal mistake.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Thursday, 25 June 2020 01:22 CDT
yvesfb

Hi Nicholas,

 

For point 2, I agree with you and may be I was not clear enough. It was not to mix all categories together (if not there is not much added value of doing categories). I was looking at the same category across languages for some categories.

For instance, if I have a "Pre-sale" category in English and an "Avant-vente" category in French, I would like that the user is not obliged to change langage interface to browse the similar tickets in another language. On the other hand I recognise that this is fine when you don't have a large number of tickets (if not the user may be disturbed if there are too many tickets in another language he/she was not looking for).

 
Thursday, 25 June 2020 21:00 CDT
nicholas

I figured you were thinking about a pre-sales contact page. My dev site is actually set up as a small software business site, complete with multilingual and pre-sales categories in Greek and English. I did think about the same thing you are thinking about now – I did build that site as if I was building a real site. Here's my thinking.

A primarily Greek speaking user is likely to be able to read English as well. A primarily English speaking user is unlikely to be able to read Greek. Mixing the two would be a disservice to the English speaking user. Moreover, the whole concept of Joomla being multi-language is that a user selects which language they want to use the site with. It doesn't make sense mixing different languages. If that was the case we would have single language sites like it's Joomla 1.5 all over again.

So, the best approach that makes sense to your clients is having separate categories for French and English. The French speakers who also speak English can switch between languages to browse international tickets. The English-only speakers will not have to be exposed to a language they don't speak and which if they saw they'd be confused and unlikely to return to your site (which is a big part of why we ask people to only post tickets on our site in English despite me speaking Greek and Davide speaking Italian natively).



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Thursday, 25 June 2020 22:51 CDT
yvesfb

Yes, and even I have some basic Greek knowledge, I would prefer to focus first on the English posts to go faster. :-)

After these exchanges, I will keep the languages separated as you suggest. :-)

 

 
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!