Should the guided tour translation really go into the sys.ini files?

@HLeithner

Should the guided tour translation really go into the sys.ini files?

I've tested on .ini and .sys.ini files and neither worked. The .sys.ini should be loaded whether the back-end sidebar menu is loaded, so IMHO it's the best place to store the translation for the Guided tours. Remember that translation should also be loaded on all pages, so the tour title will be translated when the user clicks on the "Show all tours" link.

This article states:

Provide users with the translations, as you would for any other language key for your extension.

If the translations are supposed to be elsewhere, maybe @obuisard can point us in the right direction?

If the translations are supposed to be elsewhere, maybe @obuisard can point us in the right direction?

Actually, I agree that this is where it should be to have the most visibility throughout, this is also where we have menu language keys.

Is there anything else I need to do to get this PR approved and merged?

Is there anything else I need to do to get this PR approved and merged?

Right now, no, there will probably be comments but importantly, there needs to be 2 successful tests before the release manager decides if it is going to be merged or not :-)

Should the guided tour translation really go into the sys.ini files?

Personally I think the language file should be the .ini and not the sys.ini file

Personally I think the language file should be the .ini and not the sys.ini file

Any reason why? I believe the best place for the language location is in the sys.ini file because this file is already loaded for the back-end menu. Anyway, I wasn't the one who decided about this language location, the administrator mod_guidedtours already loads the .sys.ini language files. Only the plugin doesn't, hence the PR.

tbh, I think .sys.ini is the wrong place for the guided tour translations (at least for the STEPs) and should be transferred to the .ini

guidedtours.sys.ini has 300 lines of translations which are loaded on every (backend) request. I think most of this translations should be moved to the relevant components main ini file. This pr make sense at least for the "title" of the tour but not in the plugin, this should be loaded in the module which shows the tour selection.
But not for the step title and description it should be already loaded by the component it self . ymmv

@HLeithner, I understand your point and I agree with you that only the Guided Tours Title should be in the .sys.ini file and the Steps in the component's .ini. I have changed the PR accordingly.

I talked to @bembelimen yesterday about this and he told me that guided tours could have steps about multiple extensions which means that this method doesn't work. it would mean if you create a tour for your backend users in more then one language which uses different extensions you would need to split the translation into each extension. Also this is more problematic if you try to include core extensions and not your own extensions into this tour...

tbh not sure how to solve this at the moment. I'm open for suggestions

Surely the best option is for all the language strings for a tour to be in its own self-contained language file. This would also allow third parties to create their own tours for installation that are independent of any original source

Surely the best option is for all the language strings for a tour to be in its own self-contained language file. This would also allow third parties to create their own tours for installation that are independent of any original source

I also thought about something like com_xyz.guidedtour.ini or similar, not sure if this solves the real problem.

I also thought about something like com_xyz.guidedtour.ini or similar, not sure if this solves the real problem.

That still semantically ties the tour to the component

That still semantically ties the tour to the component

exactly

That still semantically ties the tour to the component

exactly

which we don't want when you have multiple extensions in the tour

Some thoughts.

Tours could be provided by multiple 'actor' types - they all have slightly different language handling issues. Sources of tours include:

1. Part of core Joomla
2. Installed as part of an extension package
3. Extra tours from extension provider (freemium pricing model??)
4. Site integrator could provide as training material to clients
5. Training provider could provide package of tours

Language handling (following the above breakdown) could be

1. Component specific guided tours ini files e.g. com_content.guidedtours.ini - ideally these files would only loaded/parsed if a tour was active (not currently possible because of use of javascript sessionstorage with no equivalent PHP session data). As you change components for a multi-component tour you should pick up the language strings for the portion of the tour.
2. Could use same as 1. BUT problematic if a multi-extension tour using core components as part of the tour e.g. com_categories or com_fields. Also same problem if the extension is a custom field - you would need to pick up the plg_fields_extensionname.guidedtours.ini in addition to com_fields.guidedtours.ini
3. Not easy
4. Not easy
5. Not easy

3-4 suggests to me the need to be able to attach language files to a tour in some way as an alternative mechanism to language files following a naming convention. This is a different way of dealing with language strings primarily because the tour won't have a unique name we can pick up on. The language strings could possibly to be stored as json objects in a database table mapping tour id, language and json translations field.

In extremis you may need an override mechanism for the json translations e,g, in scenario 3 and 5 above a site integrator may be using custom strings in an extension for their clients (e,g, renaming an extension) and they may want the tour to be consistently worded. Using existing Joomla overrides for the global guided tours ini file would make this possible.

I would say, that the GuidedTours translation should not be part of target component. Because it not part of target component logic. In oposite to category/tags extension, which are, for example, part of content component.

The translation should come from extension that provide a Guided Tour.

The translation should come from extension that provide a Guided Tour.

This would probably be the easiest way, however we would need to duplicate lots of language strings for multi-component tours.

I liked the option to have a com_ext.guidedtours.ini file. What about if there was an @import feature in .ini files, similar to what we have in CSS? This way extra tours from extension providers could easily use the same language strings. This wouldn't solve problems 4 and 5 that @GeraintEdwards raised, but I believe would solve 1, 2, and 3. Wouldn't it?

I like the idea of guided tours specific language files.
Following on the ideas above and the constructive conversation here:

• com_[extension name]_guidedtours.ini (containing tours only) could be loaded whenever the guided tour module is enabled
• com_[extension name]_guidedtours.sys.ini (containing steps only) could be loaded whenever a tour is starting.

This could be extended for extension and training creators and site integrators with something like:

• com_[extension name]_[additional name]_guidedtours.ini
• com_[extension name]_[additional name]_guidedtours.sys.ini

(Note: not sure how to enforce those additional names to be unique, maybe use a similar convention used by namespaces).

We can tie the tours to extensions because every functionality comes from an extension in Joomla.
Then this naming convention can be applied to the site part once we extend the functionality to the frontend in the future.

@obuisard the 'additional name' part is the really tricky part. These tours will not have 'names' that are guaranteed to be unique or easily tracked/maintained. That is why I wondered about storing language strings for imported tours in a database table.

When a tour is created, installed or imported it will get its own unique ID but that is website specific and not tour specific - we can use this tour id to map to a translations table.

The other possibility is some sort of GUID/UUID naming convention but that is far from transparent and difficult to keep track ok.

@obuisard the 'additional name' part is the really tricky part. These tours will not have 'names' that are guaranteed to be unique or easily tracked/maintained. That is why I wondered about storing language strings for imported tours in a database table.

When a tour is created, installed or imported it will get its own unique ID but that is website specific and not tour specific - we can use this tour id to map to a translations table.

The other possibility is some sort of GUID/UUID naming convention but that is far from transparent and difficult to keep track ok.

We could use the naming convention:
com_[extension name]_[company name]_[package name]_guidedtours.ini
com_[extension name]_[company name]_[package name]_guidedtours.sys.ini

com_content_jamtraining_tutorials_guidedtours.ini would be the translated tours for the content tutorials created by the company JamTraining.

We could allow the name to have no 'package name' at all, just the name of the company that produced the tours.

Any company is then responsible for making the filenames in there infrastructure unique.
No need to add an extra database table.

@obuisard , that would be nice, then you'd need only one more "creator_alias" or "company" column in #__guidedtours database table. Am I correct?

@obuisard , that would be nice, then you'd need only one more "creator_alias" or "company" column in #__guidedtours database table. Am I correct?

Having an extra column could be an option.

Personally I think we need an extra column for the 'unique identifier' for other reasons, such as generating links to imported tours etc. There may be merit in capturing author and company information (possibly author/company URL, copyrights??) too - we do this for extensions already.

Close in favor of #41161 which proposes a complete re-structure of the language files and when they are called for proper use by third party extensions and maintainers.