1364809 - Add gettext support to KumaScript macros

Status: RESOLVED DUPLICATE of bug 1340342

(developer.mozilla.org Graveyard :: KumaScript, enhancement)

Description

[John Whitlock [:jwhitlock]]

What feature should be changed? Please provide the URL of the feature if possible.
==================================================================================
Currently, JSON structures are used to store localizations of translated strings in KumaScript macros.

A gettext library such as node-gettext [1] or jed [2] could be added to KumaScript. Translations could be extracted to .po files, and be made available on Pontoon [3] for the MDN localization community to translate.

[1] https://github.com/DanielBaulig/node-gettext
[2] https://github.com/messageformat/Jed
[3] https://pontoon.mozilla.org/projects/mdn/

What problems would this solve?
===============================
Currently, translators have to be comfortable with EJS and GitHub pull requests to translate KumaScript macros.  However, these are executable JavaScript files, and these PRs have to be reviewed as carefully as logic changes, which can take a long time (see mozilla/kumascript#142).

This means that macros are slowly and sparsely translated.  It also means translation strategies are sometimes subtly different between files.

Moving translation to gettext and Pontoon would standardize string translation across macros, and should accelerate translating macros into more supported MDN languages.

Who would use this?
===================
KumaScript macro developers, localizers, and staff

What would users see?
=====================
Macro authors would use gettext-formated English strings in macros. For example, the DeprecatedBadge macro [4] currently looks like:

--- Current ---

var titleAttrValue = mdn.localString({
    "en-US": "This deprecated API should no longer be used, but will probably still work.",
    "fr"   : "Cette API obsolète ne doit plus être utilisée, mais elle peut continuer à fonctionner.",
    "ru"   : "Это устаревшее API больше не должно использоваться, но оно по-прежнему может работать.",
    "ja"   : "これは非推奨 API です。未だ動作しているかも知れませんが、将来的に削除される可能性があります。"
});
var str = mdn.localString({
    "en-US": "Deprecated",
    "fr"   : "Obsolète",
    "ru"   : "Устарел",
    "ja"   : "非推奨"
});
if ($0) {
    %><span title="<%=titleAttrValue%>"><i class="icon-thumbs-down-alt"> </i></span><%
} else {
    %><%-template("SimpleBadge", [str, "deprecatedBadge", titleAttrValue])%><%
}

--- End Current ---

After the change, the English strings are used directly, wrapped with a gettext call:

-- New ---

if ($0) {
    %><span title="<%= gettext("This deprecated API should no longer be used, but will probably still work.") %>">
      <i class="icon-thumbs-down-alt"> </i></span><%
} else {
    %><%-template("SimpleBadge", [gettext("Deprecated"), "deprecatedBadge", titleAttrValue])%><%
}

--- End New ---

A periodic process would extract these strings to get text's .po files and commit them to the repo.

Localizers would use the familiar Pontoon interfaces to translate strings in macros.

[4] https://github.com/mozilla/kumascript/blob/master/macros/DeprecatedBadge.ejs




What would users do? What would happen as a result?
===================================================
KumaScript authors would use English strings in macro source, and macro logic would be simpler to read.

Localizers would add more translations in more locales, making for a better experience for non-English speakers on MDN.

Automated testing would validate that translation files are syntactically correct.  Staff would focus on reviewing macro editing PRs, and would not spend time on translation PRs.

Is there anything else we should know?
======================================
This bug should just cover the effort in:

* Adding a gettext library
* Creating and documenting the string extraction process
* Setting up a project on Pontoon
* Changing a few sample macros

The community can then take over the process of converting existing macros to use gettext.

Comment 1

[John Whitlock [:jwhitlock]]

YF's bug is the first one - I'll add my ideas as a comment to that one.