Commented on the Google discussion:
As far as I remember, this was done to let a user re-install (including the lang files) an extension accidentally uninstalled.
If it is nevertheless decided to delete these, the related xmls would also need to be corrected as they include the language/ folder in the path.

xml files updated to remove reference to language files

The way the xmls have been corrected is wrong.

If we commit this PR (which I am not specially in favor as there was a reason we added the files in the first place), then we should just take off the language/en-GB/ folder path in the .
i.e.
do

<languages>
        <language tag="en-GB">en-GB.mod_multilangstatus.ini</language>
        <language tag="en-GB">en-GB.mod_multilangstatus.sys.ini</language>
</languages>

as we do elsewhere in core, example:

    <languages>
        <language tag="en-GB">en-GB.mod_breadcrumbs.ini</language>
        <language tag="en-GB">en-GB.mod_breadcrumbs.sys.ini</language>
    </languages>

OR change ALL core extensions to not use the

<languages> 
[...]
</languages>

As our core extensions serve as example to people, I let you guess where I stand.

If you want to make core extensions as an example (something I am not
disagreeing with) then they ALL should be consistent not just a few random
ones

I see what you mean about the way I changed the xml - I will update the PR
correctly for that

On 23 January 2015 at 09:57, infograf768 notifications@github.com wrote:

The way the xmls have been corrected is wrong.

If we commit this PR (which I am not specially in favor as there was a
reason we added the files in the first place), then we should just take off
the *language/en-GB/ * folder path in the .
i.e.
do

en-GB.mod_multilangstatus.ini
en-GB.mod_multilangstatus.sys.ini

as we do elsewhere in core, example:

<languages>
    <language tag="en-GB">en-GB.mod_breadcrumbs.ini</language>
    <language tag="en-GB">en-GB.mod_breadcrumbs.sys.ini</language>
</languages>

OR change ALL core extensions to not use the

[...]

As our core extensions serve as example to people, I let you guess where I
stand.

—
Reply to this email directly or view it on GitHub
#5872 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

You know what I cant be bothered - you're never going to commit it as you
dont like any change to make Joomla consistent etc if it might touch a
language file even if that language file is out of date and unused.

On 23 January 2015 at 10:09, Brian Teeman brian@teeman.net wrote:

If you want to make core extensions as an example (something I am not
disagreeing with) then they ALL should be consistent not just a few random
ones

I see what you mean about the way I changed the xml - I will update the PR
correctly for that

On 23 January 2015 at 09:57, infograf768 notifications@github.com wrote:

The way the xmls have been corrected is wrong.

If we commit this PR (which I am not specially in favor as there was a
reason we added the files in the first place), then we should just take off
the *language/en-GB/ * folder path in the .
i.e.
do

en-GB.mod_multilangstatus.ini
en-GB.mod_multilangstatus.sys.ini

as we do elsewhere in core, example:

<languages>
    <language tag="en-GB">en-GB.mod_breadcrumbs.ini</language>
    <language tag="en-GB">en-GB.mod_breadcrumbs.sys.ini</language>
</languages>

OR change ALL core extensions to not use the

[...]

As our core extensions serve as example to people, I let you guess where
I stand.

—
Reply to this email directly or view it on GitHub
#5872 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Closed - not wasting my time on arguing

Where exactly was this decided @infograf768? The only reference I can find off hand is you committing stuff (see 592083a) and that is the only commit that predates 1.6's stable release. Every other extension in this PR was added after that time which to me demonstrates that there is a lack of consistency in the review process or an undocumented process which needs to be documented. Either way, everything across the board should be consistent and shooting this PR down just makes it harder to do that.

I'm in favor of removing this files as they are outdated and duplicated. Having the same language file in two different locations would be a very bad example for 3rd parties.

There are two possible ways to deal with our language files:
1. Best would be to have the language files in the extension folder. That is what all 3rd party extensions should do. They should not install into the language folder at all. We only do that in core because it's easier for our translators. The global language folder is an override place. It's the place where language packs (core and 3rd party) should install into, but it's not the place where the files shipped with extensions should be.
2. Since (1.) is currently not possible because it first needs changes in the translation workflow, we should have all language files in the global language folder. Which is what this PR wanted to do.

We need to change the translation workflow sooner than later so we can place our language files into the proper locations. Especially for the decoupled extensions where we made a compromise for now for the language files.

I don't think we've ever told 3rd party extensions they should put lang files in their extensions. I certainly can't find any documented reference to that. Personally I think that having all the files in a central location is much more beneficial. We have the overrides folder if people want to override content. The en-GB strings etc then belong in the en-GB folder etc etc.

I did not shoot the PR down folks, I wrote "I was not specially in favor of it", which is quite different: I barely said that we had decided in PLT at the time (1.6-2.5) to add the language folder there, because some people were complaining that they could not reinstall the templates with their language files in case of accidentally uninstall.
Then we indeed added some new modules and, to demonstrate how the new system was working, also added the language folder. Nobody complained at the time even, and I do agree here, as there was no consistency in doing so.
As I said, if it is decided to change this, I am not the one to take the final decision on anything. But the corresponding xmls have to be normalised to cope with this change.

Perfect example of a change not being documented anywhere. In addition if you check the xml code you will see that in many of the cases the xml is actually wrong. But hey you want to have incorrect language files and bugs in the xml - go for it - you win again

I don't think we've ever told 3rd party extensions they should put lang files in their extensions.

It's certainly my understanding why we introduced and support the language files within the extension.
We eventually need to get rid of either the override folder or the global language folder because both actually do the same. We don't need more than two places where one can put the files

Imho, all extension files should be contained within the extension folder. Having them spread across the whole CMS sounds wrong to me. And seriously, finding a file withing the global language folder is quite hard since there is a pletora of them there.

Imho, all extension files should be contained within the extension folder

But we encourage devs to put their media in the media folder?

On 24 January 2015 at 19:56, Thomas Hunziker notifications@github.com
wrote:

I don't think we've ever told 3rd party extensions they should put lang
files in their extensions.

It's certainly my understanding why we introduced and support the language
files within the extension.
We eventually need to get rid of either the override folder or the global
language folder because both actually do the same. We don't need more than
two places where one can put the files [image: ]

Imho, all extension files should be contained within the extension folder.
Having them spread across the whole CMS sounds wrong to me. And seriously,
finding a file withing the global language folder is quite hard since there
is a pletora of them there.

—
Reply to this email directly or view it on GitHub
#5872 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I personally feel that having language files in one places (the languages/LAN-TAG) makes much more sense than having it spread across every extensions lang files

The only place I can see having the lang files packaged with the extension being advantageous is if you are discover installing. If you uninstall the extension normally all the files are deleted anyway. So I'm not sure I understand what the issue with where language files are placed is :/

As an extension developer myself I prefer having the language files in the same folder as the extension. It may be personal preference but I like having my code together. Also finding your language files in the long list of files all the time is time-consuming. Those were my reasons for a long time. Now that I am learning how to utilize my IDE better, it is less of an issue. It does require me to configure the IDE ;)

The only reason I know of why we encourage devs to put their media in the media folder is so that resources can be compressed and thus having less http requests for getting media files. Although this seems to be utopia :)

"I don't think we've ever told 3rd party extensions they should put lang files in their extensions."
Unless I misunderstand it, this is recommeded in this article below "Language File Location Options"
https://docs.joomla.org/J2.5:Developing_a_MVC_Component/Adding_language_management

It's easier to discover install if the languages are in the same folder as an extension. Otherwise there is no true benefit to whether the languages are in a single folder or spread out all over the system. Yes, in some ways as @Bakual said it kind of supports an override system, but that isn't the intent; it just happens to be the order in which paths are looked up. Use JLanguage's proper overrides if you're aiming to do that.

As for the media folder comparison, doing that lets people who use the API correctly override media at a template level. Otherwise again, there is no difference between whether media is there or components/com_whatever/assets.

Personal preferences aren't going to get us anywhere. Policies need to be enacted and enforced, consistently. For core extensions, for me that policy should be everything in the language folder and no language files grouped with their extensions, XML files updated as such. Yes, there is a hypothetical scenario of people uninstalling core extensions and needing them again later; efforts to decouple stuff will address some of that by creating installable packages. For the rest of the extensions, in some ways I'm going to go with a tough luck stance; you can find the files you need and drop them in the right spots.

As a translator I like to add a POV:

1. The files Brian reported:
   Easiest way, just delete them, translated files are not in there anyway. If they were used as an example, I'd suggest to create a part here on github with example packages of a template/plugin/component/module for developers outside the CMS package.

2. As a translator I am very much in favor of keeping the language files in two main folders (the language and the administrator/language folder) and not spread out over all the extensions. Despite understanding the developers pov, as a translator that would be a big pain to maintain, not to mention the work we do creating localized packages.

Overall, as a translator I don not (or is it don't ;)) want to be in the way of moving forward and hold up new development. But just a small remark that a bit of help and some tools that would help translators would be very much appreciated by them. The past has shown that this is often a part that is not that much considered. (no offence, or no offense, which ever you prefer)

as a translator that would be a big pain to maintain, not to mention the work we do creating localized packages.

Imho, language packs should always install into the global folders, They are basically an own extension and should never install into the extension folder where they could possibly overwrite existing files. That's also my reason why extension should not install their files into the global folder.
Let me explain what I wod with my extension and you see what I mean.
When you install SermonSpeaker, it will install with en-GB and all available translations. Those files are put into the extension folders.
Now someone finds an error and fixes it on Transifex. Their webhooks trigger an event on my site and cTransifex will create a language pack with the updated files.
If the user needs the update language file, he can just go and install the language pack (even from the backend of SermonSpeaker). This pack will install into the global language folder, overriding but not overwriting the orignally shipped files.
Both extensions (SermonSpeaker as well as language pack) can be uninstalled independant and without issues. Both also can be updated without messing up the other one.
That's how it should and does work from my point of view.

In theory, your workflow works great, but I don't see the main language folders as an override folder for your extension. But because of the order of path lookups, this is exactly what is able to happen. My biggest gripe about the existing setup is that it adds an unnecessary layer of complexity and features that go against the API design (there's a reason we have the overrides folder within the language folders).

Separate rules for core and third party extensions is bad too. I'd almost argue to deprecate either extension level language folders; everyone should play by the same rules regardless of who wrote the extension or whether it's preinstalled in a package you can acquire from joomla.org.

I agree with @mbabker here that we should have the same set of rules for everyone. The way languages are loaded has been confusing me for sometime already. If we can just say the languages are loaded from the language folder (as there would only be one) and overrides from the override folder, it would be a lot clearer. The code for it would most likely be cleaner as well.

If the order of path lookups changes one day, we might be in deeper problems :)

I also agree that all extensions should use the same rules.
However I see the use for three locations because we have to deal with language packs. These are a bit a special case of an extension. They deal with other extensions output but should obviously not modify the files of those extensions.
So I see

• the extension language folders as the place for the originally shipped language files, packed with the extension. Be it only source or also prepacked translations.
• the global language folders as the place for language packs, be it for core or 3rd party extensions.
• the override folders for changes made by the user manually.

This way each extension type has its own place to live and doesn't mess with eachother.
I agree that it can be confusing and could be improved for sure. However I wouldn't remove the feature just to make things simpler. The code for it is actually not that bad :)

Maybe going slightly off topic here, but I just got scared a little bit by "...almost argue to deprecate either extension level language folders..." :-)

I'm frequently updating one out of 50+ translations of a large extension with with 5000+ lines in 40 (core) language files. About a year ago or so, the developers decided to move language files away from the central language folders into extension folders. As a translator, I first didn't like that, but after a short time I got used to the new structure and for me it now doesn't make a lot of difference. I think the vast majority of translators (those who actually contribute translations) do not translate plenty of different extensions. So the familiarisation time should be very short - like it was for myself.

From the developer's point of view (I'm not a developer), having the language files in their extension folders is in line with the OOP aproach, which is also in line with the Joomla goal to 'modulize' the CMS. If the language files are relative to the extension folder, they just have to pack the folder and the pack is directly the installer. This way the extension is 'encapsulated' from the rest of Joomla and last but not least can be more easily reused for other systems like WP. If all language files are centralised, you need some additional handling for them. Also, when the extension is uninstalled, deleting the extension folder also deletes the extension language files, which imho may result in less orphaned language files.

I'm not saying we currently have a perfect system, but it works and provides sufficient flexibility. The extension I'm dealing with is distributed with English language files only in order to not waste space and resources. Translations are primarily managed on Transifex (but Translators are not forced to use it). Then we use ctransifex to create downloadable language packs (There is a link to additional languages at the end of the extension's installation process). However, ctransifex currently is unable to position language files outside the global language folders.
So the extension's source files, which also serve as a fallback when a translation is missing, are in the extension language folder and the translations end up in the global Joomla language folders. In case of this extension, it is also important to have the language override folders available, because virtually every user needs to customize some strings for his/her specific business.

Basically I tend to agree with Bakual. I wouldn't mind if Joomla would generally use the relative files approach and use the global language folders primarily or exclusively for translated language packs - the latter being easier for translators.

...just my two cents

My experience is that it is unlikely that all Joomla registered languages are proposed for each extension.
Therefore, as we can install extension languages via the "file" mode, some lang communities install these in core folders

It took me a while to catch the mechanism of overriding one file (in the extensions folder) by another (in the CORE language folder). Unfortunatelly, it is not / not well documented. But I'm also unhappy, that some Joomla core extensions does not support this mechanism: I detected this in the finder component and in the postinstall message component.
So a clear statement how to handle language files in the future would be helpful.
Imho the 'local' language files are a good way, as @Gitjk explained.