Show Advanced KnowledgeHide Advanced Knowledge

Uninstall Local Changes

1 Requirements

To get rid of local changes of a language you currently need to activate the extended language maintenance and delete all local changes in the database. It would be more convenient if the langauge admistration table would offer an option "Uninstall local changes".

2 Additional Information

• Idea / concept: Kunkel, Matthias [mkunkel]
• Interest in funding: ILIAS-Verein
  
• Maintainer: Neumann, Fred [fneumann]
• Implementation of the feature is done by  Neumann, Fred [fneumann]
• Testcases by: Kunkel, Matthias [mkunkel]

3 Discussion

Neumann, Fred [fneumann] June 22, 2016:
I support the request as maintainer of the language service. Additionally I propose the following further changes:

1. Abandon the option "Save all changes to the local language file" on the Maintenance tab of a language. As the language maintenance allows to export the local changes, this function is normally not needed. It has the problem that multiple clients save to the same file (see Mantis #11543).
2. Alternatively show the "Save all changes to the local language file" only if LANGMODE="1" is set in the client.ini.php. This would change the available options on the maintenance tab of a language:
   • Standard options:
     • Load local language file into the database
     • Clear local changes in the database
   • Additional LANGMODE options (Matthias can tell which of them are really used in the ILIAS language installation):
     • Save all changes to the local language file
     • Delete local additions in the database
     • Delete the local language file
     • Merge local changes into the global language file
3. The "Save all changes to the local language file" silently copies the global language file to the folder of local language files. If you use this function before an ILIAS update, you can use the filter  "local and update changes" on the edit screen after the update to view conflicts between your local changes and changes coming with the update. This side-effect can be moved to a new option "Remember the global language file to compare it after an update"
4. Add the filter "Identifier" to the edit screen of a language (good for development).
5. Abandon the switch "Enable/Disable Extended Maintenance" in the global language settings. It is not really needed. Users need read and write permission in "Administration >Languages" for the exended maintenance which is currently also sufficient to activate/deactivate this. The original reason for the switch may have been usability, but I think there is more complexity in other parts of the ILIAS administration.

If the extended maintenance is not explictly switched, then the "Refresh" function in the language list will have to check if local changes exist in the database and then show the following confirmation message:

"ILIAS found locally changed language variables. Refreshing a language will read the global language file and probably a local language file to the database. A global file will not affect your changes. A local file will overwrite your changes that are older than the file date. Do you really want to refresh the selected languages?"

The list of languages below this message can show if changes will be overwritten. For this we should add an index on lng_date.local_change.

Neumann, Fred [fneumann] June 22, 2016:
The terms "global language file" and "local language file" are not intuitive and can lead to misunderstandings because local language files are stored in "Customizing/global/lang". Should we rename them to "standard language file" and "custom language file"?

JourFixe, ILIAS [jourfixe], JUL 04, 2016: We highly appreciate Fred's suggestion and schedule the feature for 5.2. We prefer option 1 (abandon the option "Save all changes to the local language file") instead of 2. We agree with the name changing "global language file -> standard language file" and "local language file -> custom language file".

Kiegel, Colin [kiegel] 2016-07-04: Regarding Point (3) of Freds comment:
ILIAS currently needs to save "copies" of global lang files to allow a 3-way merge, if the lang files change due to an update. However this approach seems flawed, due to the following reasons

1. it requires user action to create copies of the global lang file. If the administrator forgets to do this, future language will make wrong assumptions.
2. it does not handle custom lang files (yes, there are scenarios where there can be client-specific changes to custom lang variables). It may not be apparent to ILIAS administrators, that there is a difference between language variables coming from the custom vs. global lang files, which may also lead to unexpected behaviour. This problem occurs, if a local lang file changes after making adjustments in the client.

Right now, i.e. before the proposed changes, both problems are already present. They make language administration unneccessarily complex. What we really need is a way to

1. store copies of original lang entries automatically as needed, but without extra user intervention
2. also handle custom lang files for a unified user experience

Proposed alternative: Whenever a language variable is edited for the first time, ILIAS will save the original variable in a backup table. Unchanged variables should not be in the backup table. This backup table can then be used for 3-way merges, to determine which variables have been changed both locally in the client and during the update. During the merge, the backup-table must be updated with the new "original values" if they changed. Backup entries must be deleted, if a variable (or the whole language) has been reset. 

4 Implementation

2016-08-25: Feature is committed to the trunk:

• New function "Uninstall local changes" in Languages Overview
• Abandoned 'save changes to local language file'
• New function 'Backup the standard language file'
• Added the filter "Identifier" to the edit screen of a language
• Abandoned the switch "Enable/Disable Extended Maintenance"
• Renamed global and local language file
• Created index on lng_data.last_change

Test Cases

Test cases completed at 2016-08-29 by Neumann, Fred [fneumann] (Test Suite Language Handling)

• C13065 Übersicht installierter Sprachen
• C13066 Suche nach Sprachvariable per Identifier
• C13067 Ändern einer Sprachvariable
• C13068 Aktualisierung einer geänderten Sprache
• C13069 Aktualisierung aller Sprachen mit geänderter Sprache
• C13070 Lokale Änderungen entfernen
• C13071 Backup der Standard-Sprachdatei erzeugen
• C13072 Vergleich der Änderungen mit Backup

Approval

Approved at August 29, 2016 by Kunkel, Matthias [mkunkel].