View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005646 | Composr | core_language_editing | public | 2024-03-22 17:57 | 2024-03-30 14:41 |
| Reporter | Patrick Schmalstig | Assigned To | |||
| Severity | Feature-request | ||||
| Status | non-assigned | Resolution | open | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0005646: Add lang_rephrased directory | ||||
| 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. | ||||
| 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. | ||||
| Tags | Roadmap: Over the horizon | ||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
Automated message: This issue was created using the Report Issue Wizard on the Composr homesite. |
|
|
This is a narrow solution to a wider problem: overrides getting replaced when a bundled-addon is upgraded. The same problem exists for templates, and even for code. It would be pretty normal for the code in non-bundled addons to be altered too, because these addons are often very specific rather than general purpose and hence more likely to need customising. 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. |
|
|
Sure this isn't a 100% fix, but it IMO does get us closer. And I believe it is a big enough problem to address at least to the capacity I suggested, which wouldn't be that hard to implement at some point. We can't expect users to diff non-bundled addons. Not only is diffing mostly a tool aligned on the developer end, but IMO no one should be expected to have to diff and merge code which they didn't modify (e.g. non-bundled addons are not inherently modified). Having such expectation exposes the fact our plugin / non-bundled addon system in itself is flawed; I know no other software where users are expected to diff after installing an addon (unless it's a custom addon not supported or distributed by the core developers of the software). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-03-22 17:57 | Patrick Schmalstig | Tag Attached: Roadmap: v11 | |
| 2024-03-22 18:03 | Patrick Schmalstig | Description Updated | View Revisions |
| 2024-03-22 18:03 | Patrick Schmalstig | Additional Information Updated | View Revisions |
| 2024-03-22 18:05 | Patrick Schmalstig | Description Updated | View Revisions |
| 2024-03-22 20:23 | Patrick Schmalstig | Additional Information Updated | View Revisions |
| 2024-03-22 20:24 | Patrick Schmalstig | Additional Information Updated | View Revisions |
| 2024-03-22 20:25 | Patrick Schmalstig | Description Updated | View Revisions |
| 2024-03-22 20:31 | Patrick Schmalstig | Description Updated | View Revisions |
| 2024-03-22 20:32 | Patrick Schmalstig | Description Updated | View Revisions |
| 2024-03-24 16:18 | Chris Graham | Note Added: 0008409 | |
| 2024-03-25 13:58 | Patrick Schmalstig | Note Added: 0008427 | |
| 2024-03-30 14:41 | Patrick Schmalstig | Tag Detached: Roadmap: v11 | |
| 2024-03-30 14:41 | Patrick Schmalstig | Tag Attached: Roadmap: Over the horizon |
