[policy, no patch] Decide and document guidelines for using string context

Created on 21 January 2011, almost 14 years ago
Updated 12 February 2023, almost 2 years ago

Updated: Comment #31

Problem/Motivation

As has been mentioned elsewhere, we don't yet have guidelines on when and how to use string contexts (= translation contexts). Due to lack of guidelines every developer/module maintainer re-invents the wheel and decides on their own context strings. This results in a great variety of contexts, some good, some not. Further, the lack of guidelines for context, makes it difficult for module/core maintainers to accept string context suggestions. As a result discussions come to a standstill or bad contexts get accepted.

For examples of real-life string context issue, see the list of issues tagged with "string context" .

Proposed resolution

Create a description of string context for both developers and translators. Including criteria for string context and examples of good and bad contexts.

Remaining tasks

String context criteria

Define a context that:

  • Fixes an actual translation problem that has been identified due to the lack of context.
  • Allows a translator to distinguish the meaning of the string and decide on the right translation.
  • Is reusable.
  • Provides information on the meaning of the string.
  • Is short and concise (phrase rather than a full sentence).
  • Only add the context to the string in the deviating context. The dominant use of the string does not receive a context.

Avoid the following in context definition:

  • Linguistic contexts like: "Verb", "Noun" or "Dative". This usually does not provide enough distinction
  • "Module name". Module names are usually not translated. If the module name is the donimant use of the string, it will not receive a context.
  • Don't use a module name. It silos the use within (groups of) modules and prevents collaboration between modules.
  • Don't use functional part of the module where the string is used (e.g. "Block"), function name or php class name. This is not re-usable and this context may change over time.

Related issues

Arguments from the original report by @zirvap

  • Context is used to give additional information about strings to translators, for strings which would otherwise be difficult to translate well.
  • General rule of thumb: If a string has several possible meanings (ie. "May" which can be both the complete month name and a three-letter abbreviation of the name), we use the bare string for one meaning, and add context to others. For instance: "May" without any context is the abbreviation, "May" with context "Long month name" is the complete name.
  • Contexts should be reused. (For instance, a contrib module should not introduce "May" with context "Complete month name", it should reuse the core context.
    ( #1034882: Make list of contexts used more evident for developers is necessary for this)
🌱 Plan
Status

Needs review

Version

9.5

Component
Documentation 

Last updated 2 days ago

No maintainer
Created by

🇳🇴Norway zirvap

Live updates comments and jobs are added and updated live.
  • Coding standards

    It involves compliance with, or the content of coding standards. Requires broad community agreement.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇮🇷Iran tsotoodeh

    In my opinion, documenting context strings and implementing a filter based on these type of string is a necessity. Without proper documentation finding context strings is not an easy task, indeed.
    Such situation would lead to over defining what is already at hand, The example would be a date format strings required (l, F j, Y - H:i) in multilingual website, many people create and customize a new format without knowing that the format string could be translated.

Production build 0.71.5 2024