ttag-org / ttag

:orange_book: simple approach for javascript localization
https://ttag.js.org/
MIT License
345 stars 44 forks source link

Handling untranslated entries in ttag lib #111

Closed MrOrz closed 6 years ago

MrOrz commented 6 years ago

I am setting up webpack with ttag under development environments.

I found that the way ttag lib handles untranslated entries (i.e. msgstr "") is different from the way babel-plugin-ttag does. In babel-plugin-ttag, it resolves to default locale by default; however, ttag lib just resolves to empty strings.

Since gettext-parser.po() does not provide us ways to filter out untranslated entries, I think we should handle this within ttag lib.

There are 2 ways to handle untranslated entries:

  1. modify the implementation of t, jt, gettext, ngettext in ttag lib to match the implementation of babel-plugin-ttag/resolve.js's no-translation handling.
  2. modify the implementation of addLocale(locale, poData) so that it filters out untranslated entries within poData. This involves changing the logic of transformTranslateObj(translationObj) in utils.js

Personally I prefer method 2 because it is simpler, but method 1 provides more flexibility -- we can implement no-translation warnings / errors similar to babel-plugin-ttag's if we use method 1.

I am happy to send PR for this, but I would like to ask for your opinion on choosing method 1 or method 2.

AlexMost commented 6 years ago

You are right, that behavior must be consistent. Seems like we can fix that with adding one extra check to findTransObj here - https://github.com/ttag-org/ttag/blob/master/src/index.js#L38.

Here is a similar check in the babel plugin

export function hasTranslations(translationObj) {
    return translationObj[PO_PRIMITIVES.MSGSTR].reduce((r, t) => r && t.length, true);
}

Would be great if you will send a PR!