#5646 - Add lang_rephrased directory
| Identifier | #5646 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Add lang_rephrased directory |
| Status | Open |
| Tags |
Roadmap: Over the horizon (custom) |
| Handling member | Deleted |
| Addon | core_language_editing |
| Description | Add a new lang_rephrased directory in addition to lang and lang_custom. It should have the same structure.
When using rephrasing: * If the language codename did not yet exist, it is placed in lang_custom. * If we are rephrasing an existing codename, it is placed in lang_rephrased (regardless if the original codename was in lang or lang_custom). The language compiler compiles language strings using this new order, in order from lowest to highest priority: * lang * lang_custom * contentious_overrides * lang_rephrased lang_rephrased is never included in releases (except for the structure itself) because it always contains site-specific overrides, not software-specific ones. lang_rephrased should be treated similar to uploads. They are never addon files nor are they alien files. They are never included in releases, whether that is Composr releases or addon releases. However, they should be backed up and are still checked in file integrity for permissions. Modularisation should error when trying to include a lang_rephrased file that is not .htaccess or index.html in an addon's file list. Addons should never include a lang_rephrased file as they are site-specific. Instead, suggest to use lang_custom or contentious_overrides. |
| Steps to reproduce | |
| Additional information | Currently, all language edits are placed in lang_custom. This doesn't work out for non-bundled addons because when the addon gets updated, the rephrased language strings are lost.
Also, rephrased strings might get overridden by contentious_overrides. This is not desired either. Rephrases from translate/rephrase the software should take the highest priority because admins may want the software to use specific terminology that is different from its default. These changes should never be lost from updates or overridden by software-defined strings. |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".


Comments
If something is "rephrased" but then the original is changed (a common enough situation), then this is a reason even the narrower problem is not actually solved.
I don't think there is a good solution to the broader problem, or the narrower problem, and adding a lot of default overhead to the structure of the system adds complexity that makes the system more complex for everyone.
I think the real solution is simply that people need to pay for the developers needed to keep addons maintained, and that we should have a free market of talent that feels empowered to sell services for that work. Or, people learn to do diffing etc themselves.