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
(Using en_fix versus changing strings in a patch)
(en_fix and different versions - thanks to David's comment in MDL-53200)
Line 21: Line 21:
* en_fix is mainly for fixing the English - typos, incorrect spelling or grammar - and not for important terminology changes
* 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
* UI string changes can require Behat tests to be fixed
==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.

Revision as of 14:04, 24 February 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

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.