Closed MrOrz closed 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!
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. Inbabel-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 withinttag
lib.There are 2 ways to handle untranslated entries:
t
,jt
,gettext
,ngettext
in ttag lib to match the implementation of babel-plugin-ttag/resolve.js's no-translation handling.addLocale(locale, poData)
so that it filters out untranslated entries withinpoData
. This involves changing the logic oftransformTranslateObj(translationObj)
inutils.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.