Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Improving English language strings: Difference between revisions

From MoodleDocs
(en_fix and different versions - thanks to David's comment in MDL-53200)
Line 24: Line 24:
==en_fix and different versions==
==en_fix and different versions==


AMOS has an in-built feature called auto-propagation that was introduced so that maintainers do not need to propagate strings manually. As a conclusion, en_fix can't be used for strings changes that are supposed to be applied on particular branches only. In other words, en_fix changes are automatically applied to DEV and supported releases, such as 3.0 and 2.9.
Previously AMOS auto-merged en_fix strings to different versions (as for all other languages). However this behaviour was changed in April 2016. Thus, from now on:
 
* For typos and spelling mistakes that should be applied to all branches, it is necessary to explicitly propagate the change to all supported versions (e.g. DEV, 3.0 and 2.9 though it doesn't matter if all checkboxes are left ticked)
* UI string changes should be committed into DEV only without propagation.

Revision as of 13:33, 19 April 2016

Changing or creating a new lang string?

New strings were required in 1.x times when we did not have branches for translations. Since 2.0, for changes in master, structural and/or semantic modification of a string (such as adding or removing {$a} placeholders etc) is acceptable as such strings are highlighted in AMOS as outdated. Of course, if lang pack maintainers do not pay attention to it, mismatch can happen - but is is considered to be the lang pack bug.

When a new string is introduced, the old one should be deprecated or removed so that unused strings do not accumulate.

Basically I see it as (for master only):
  1. Any change is allowed (semantical or structural). It does not have sense to keep the old string because there won't be use for it when the new Moodle version is released. So we can forget about the old one 100%. Of course if the string is radically different, then it may have sense to create a new, completely different string (and proceed with next point).
  2. If for any reason we stop using any string (because a feature is out or because we have decided to create a new different string instead of change existing)), then:
    • if the old string is really specific (not suitable for reuse) we can safely proceed to delete it,.
    • If the string belongs to a plugin, IMO we can also proceed to delete it (reuse of plugin strings should not be allowed).
    • But, if the string is generic (may be reused) and it's not part of a plugin then the string must be deprecated.
And, for stables, only small semantical changes are allowed. No structural, no deprecation and no deletion. Ever. If still something different must be shown it will be, always, via new string.
--Eloy Lafuente (stronk7) (talk) 19:48, 5 March 2015 (AWST)

Using en_fix versus changing strings in a patch

  • en_fix is mainly for fixing the English - typos, incorrect spelling or grammar - and not for important terminology changes
  • UI string changes can require Behat tests to be fixed

en_fix and different versions

Previously AMOS auto-merged en_fix strings to different versions (as for all other languages). However this behaviour was changed in April 2016. Thus, from now on:

  • For typos and spelling mistakes that should be applied to all branches, it is necessary to explicitly propagate the change to all supported versions (e.g. DEV, 3.0 and 2.9 though it doesn't matter if all checkboxes are left ticked)
  • UI string changes should be committed into DEV only without propagation.