many files can NOT be detected and listed by com_localise

[joomlagate]

Today I downloaded the latest dev version (v4.0.12-dev) of com_localise and tested it on Joomla 3.4.3 with Kunena 4.0.3 language files.

There are totally 15 language files in the backend language file folder of Kunena, but com_localise can only recognize and list 11 files!

Why the other 7 files were not detected and listed?

[infograf768]

Tested Kunena 4.0.5 (on Joomla 3.4.4-dev) where there are 17 language files for admin.
Only 11 files are indeed recognized by com_localise by default.

The Kunena files are present in the extension language folder. As soon as they are placed in the main core folder, com_localise displays all.

The full list of files is the following:

As you can see, the files which are not listed do not use the "normal" format name for ini files.
They contain a different dot suffix.
Example:
en-GB.com_kunena.controllers.ini

Now, go to Options and add .controllers in the Suffixes for language files, i.e.

The com_kunena.controllers.ini file now displays fine.
So, in the case of kunena, we have to add multiple suffixes...

If I place all these en-GB files in the main joomla folder and filter by kunena, I do get the 17 files but some get an inexistent status while others get an untranslated status (bug).

Now for the Site part.
This is the list of files:

As you can see, we have to add supplementary suffixes: .templates,.tpl_blue_eagle
But remains some files which are not displayed:
en-GB.kunena_tmpl_crypsis.ini does not have a normal prefix (com_, mod_, plg_, file, lib_, pkg)
en-GB.mod_kunenamenu.ini and en-GB.mod_kunenamenu.sys.ini for which I have no explanation except that there are no modules installed by kunena in the core modules folder but is present in com_kunena/install/modules/ folder

NOTE: I remarked that all these files have windows ending instead of Unix, which is bad practice.

[joomlagate]

hi, infograf768 ,

from your post, I noticed a funny issue:

The file en-GB.plg_kunena_joomla.sys.ini is located in this folder in my test:

/administrator/components/com_kunena/language/en-GB

But on your first screenshot, it seems that this file was in this folder:

/administrator/language/en-GB

Why so different?

Well, let us return to the original question: why com_localise will "miss" so many files?

You had mentioned some "suffix" cause, but my further question is: Why SHOULD I remember so many suffixes?

I think the author of com_localise should modify the rules which will be used to recognize language files. This is a translating tool, it should work in a simple way: find out language files having same filenames (except the language tag part of course) and compare them !

Do not ask users to remember and input so many suffixes there! We don't know what kind of a new suffix will be used by another extension developer. I think we should not worry about this.

Just compare the filename's part after the language tag and list them all there.

Thank you.

[infograf768]

But on your first screenshot, it seems that this file was in this folder:
/administrator/language/en-GB
Why so different?

Look better: the path is to /administrator/language/fr-FR not en-GB.
We are looking at the path to the translated files (here to French), i.e. where a translated file in the target language will be saved. The path is correct. It picks the reference file where it is (here the en-GB are in the extension folder) and will save —or update if it exists— the translated file in the core folders.
This is normal behavior. When making an extension package, it will pick the file there.

I think the author of com_localise should modify the rules which will be used to recognize language files.

You are welcome to propose patches. This component development is depending on volunteers. There is no single author.
Kunena is obviously not following the usual rules which should depend only on the type and the general suffixes used in Joomla (i.e. .sys and possibly .menu for extensions that still want to be compatible with 1.5 ...), they should use an underscore instead of that supplementary dot which de facto creates a new suffix.

I will try to look at that though and see what we can do.

[infograf768]

After checking the code, I am not sure we can even do that (i.e. using an underscore instead of the dot).
The issue is that we look for:
$file = "$path$extension/language/$tag/$tag.$prefix$extension$suffix.ini";

1. where $prefix if the type of the extension. This means that a file named en-GB.kunena.ini is wrong and will not be filtered. Prefixes (types) are com_, mod_, plg_, lib_, files_, etc. (see filters in extensions->manage or in com_localise translations page.
2. where $extension is the pure name of the extension, i.e. in this case kunena (whether it is a module, the component or the plugins)
   $extension has to be "pure" as it also defines the path to the precise extension folder.
3. where $suffix is normally .sys when present

If we do not specify all these variables, we are in bad shape, not only to retrieve the files, but also to save the translated files with the same name (except the $tag).

Basically what you ask for is totally different from present com_localise as integrated in joomla.

FYI, en-GB.finder_cli.ini is treated as a special case in com_localise.

[joomlagate]

Do you remember Translations Manager for Joomla 1.5? Which com_localise claimed to based on.

You can make a test: on Joomla 1.5 installation, you intall Translations Manager component, then, copy Kunena 4.x language files to appropriate folders of this Joomla 1.5, and you visit Translations Manager backend, you will find out that it will CORRECTLY find language files and compare them!

Does Translations Manager require any suffix input? No. It doesn't.

I don't know how Translations Manager works, but I think this is a better way.

Why com_localise did not follow this way?

[infograf768]

In 1.5, we did not have a language folder in the extension. All ini files were in core folders.

[joomlagate]

Since Joomla 3.x has a language folder in extension folder, so we need to MANUALLY input some suffixes to enable com_localise to recognize language files in those folders? This does not make any sense!

[infograf768]

We need some suffix only when some coders have defined weird ini files names.

But, as I said, you are welcome to propose patches. The code is in
ROOT/administrator/components/com_localise/models/translations.php

[infograf768]

I "may" have found a way, but it implies extensive changes and filtering issues.
Looking into it