Cleaning up old language files

Does anyone have any guidance as to how to clean up old language files. I have come to this after I tried to use a Window-based IDE and started seeing some queer behaviour with files apparently changing - but not. It derived from a filename collision between language files. Here is a small example:

./custom/modules/jjwg_Maps/Ext/Language/fr_FR.lang.ext.php
./custom/modules/jjwg_Maps/Ext/Language/fr_fr.lang.ext.php
./custom/modules/Notes/Ext/Language/fr_FR.lang.ext.php
./custom/modules/Notes/Ext/Language/fr_fr.lang.ext.php
./custom/modules/ProspectLists/Ext/Language/fr_FR.lang.ext.php
./custom/modules/ProspectLists/Ext/Language/fr_fr.lang.ext.php

In a Linux filesystem, fr_FR.lang.ext.php is not the same as fr_fr.lang.ext.php. But in Windows filesystem, they are the same file. I have the same for ru_ru vs. ru_RU & nl_nl vs. nl_NL. My IDE doesn’t handle it very well.

I don’t have any language packs installed so these files are from previous versions of SuiteCRM which have been upgraded version after version. Some come from the paid version of Security Suite.

There is a discussion about case sensitivity here: https://suitecrm.com/forum/international-language-support/6681-italian-language-package-problem-file-names#24194

Is there any documentation that explains the old layout and the new layout of language files?

Cheers

I had a long battle to remove those languages from SuiteCRM install package.
When I find a language file I ask for its removal at github but they keep creating new ones so ther is never a clean install.

Nobody should have languages files around if they don’t have language packs installed. Its a wast of space, size and time when quick repair or backup.

On my computer I always make a clean suite pack by searching (using the language code as wild cards) and removing files.
Tedious I know… but it works!
I keep that clean pack for later file diffs with new versions.

You can also install and remove a language pack (or create a fake one, just manifest, no files).
Uninstall that language pack and all files with that language code will be uninstalled (also tedious!)

Thanks @horus68. This seems to be a major pastime for you. Although I use en_us, I applaud your efforts for the wider SuiteCRM community because it helps focus minds on cleaning up SuiteCRM generally.

Are there any guidelines for module writers? It might be a good idea to post something on Sugar Outfitters who provide a load if extensions and Security Suite in particular.

I am concerned about case sensitivity for language specs in the light of my own problem and the fact that Windows is case-preserving but case-insensitive. There is scope for filename collisions as I have. Where in SuiteCRM is the selected language specified? and are the language files read in as case-sensitive or case-insensitive?

I can remove unwanted languages for all modules but what is the plan for add-on modules in other languages which I’ll also remove with the command below:.

find <SUITECRM> . \( -iname \*ru_ru\* -o -iname \*es_es\* -o -iname \*fr_fr\* -o -iname \*nl_nl\*  -o -iname \*fi_fi\*   -o -iname \*de_de\*    -o -iname \*ua_ua\*   -o -iname \*ge_ge\*  -o -iname \*hu_hu\*  -o -iname \*it_it\*  -o -iname \*pl_pl\*  -o -iname \*pt_br\*  -o -iname \*sp_ve\*  \) -exec rm {} \;

using the list of languages found in custom/Extension/application/Ext/Language

In config.php, edit the languages array to remove all but en_us.
Repair And Rebuild; Rebuild JS Language Files

Is there anything else I need to do?

Cheers

I also did asked before for some guidelines on SuiteCRM case but there are not!
It also affects non language files (I can remember 1 image file in templates and last version brings 2 more in modules maps) .
When unzipping in windows system they are overwritten!
You can also see that folder names do not have any rule, some start by capital letter others don’t. This causes issues when ordering folders by name!
I hope that those little issues could be solved in a near future by moving away of SugarCRM core and bring some clean rules for a new suiteCRM

On the actual language packs:
Language packs created via Crowdin they are using name specs as xx_XX but that was a decision of mine making it accordingly language codes specs.

One more pull request to clean up latest files
https://github.com/salesagility/SuiteCRM/pull/953

Note on your custom folder:
Custom folders has been cleared from all language files since 7.5

And in accordance with RFC5646 :slight_smile:

True!
Some copy past to future knowledge:

de_AT – German for Austria
de_DE = German for Germany

Note the standardized use of the underscore and the style of capitalization in the examples:
lower case letters to indicate language (ISO 639) followed by underscore followed by upper case letters to indicate the country code (from ISO 3166).

ISO 639-1 defines two-letter language codes for many languages and can be found at http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes.

ISO 3166-1 defines two-letter country and can be found at http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2.