bugGNU gettext - Bugs: bug #50920, support Javascript template...


You are not allowed to post comments on this tracker with your current authentication level.

bug #50920: support Javascript template strings in xgettext

Submitted by:  Philip Chimento <ptomato>
Submitted on:  Tue 02 May 2017 11:14:55 PM UTC  
Votes:  405  
Category:  JavaScript Severity:  4 - Important
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

( Jump to the original submission)

Thu 25 Oct 2018 05:03:03 AM UTC, comment #10:

Thank you for the patches, Marco. The general approach (discarding template strings with any substitutions) sounds reasonable.

However, I think it is not straightforward to determine the end of template strings, because substitutions may be nested; for example, this is a valid template string:

Maybe, it could be based on the backtick support in the shell-script scanner, which takes into account of nesting.

Daiki Ueno <ueno>
Project Administrator
Fri 07 Sep 2018 02:21:49 AM UTC, comment #9:

While I agree that supporting template strings with placeholder is wrong, I think is actually safe to support template strings when they only contain normal text.

In any case, these strings should be properly parsed, and we should not ignore them in case they contain a mix of apices.

For example a code like this:

A part of warn, it generates something like:

Attached here, two patches that fix this.
The 1st one, just add support for the backtick (`) strings, while the second one, discards them when they use javascript placeholders (so basically if there's a "${" inside; and that's enough to respect the JS syntax).

In case --extract-all is passed we warn about this misusage, however I'd love to do this in all the cases a template string is passed to a gettext flag (i.e., only if we do _(`${foo}`), and not if we've just a print(`${foo}`) call).

I've tried to do that, but unfortunately there are some xgettext limitations at core level that make this quite annoying to do only changing the javascript parser.

Ideally, I'd like to have a function that is called once the messageid is extracted, just before the format parsing, and that can be used to verify the content of the string, to check if this is legal or not.
I've tried to get the same with a literalstring_parser, but that's not doable because it doesn't handle nullified msgid's, and that's a too late stage.

Anyway, the two commits here should fix the main issue, in the mean time we don't decide to have something with a nicer feedback.

(file #44949, file #44950)

Marco Trevisan <trevinho>
Wed 25 Jul 2018 03:22:39 AM UTC, comment #8:


David Mosberger-Tang <dmosberger>
Wed 18 Jul 2018 12:34:56 PM UTC, comment #7:

Same issue here and it's a real PITA.

Bruno Desthuilliers <brunoblookup>
Wed 04 Oct 2017 03:05:10 PM UTC, comment #6:


We get the same issue, it is quite painful if we want to use recent version of JavaScript.

How can we help to resolve this issue?


Nicolas Terray <nterray>
Fri 12 May 2017 12:09:25 PM UTC, comment #5:

This is a little bit more serious than simply not extracting such strings - it sometimes breaks parsing of the JS file even if a template string is not used in connection with gettext. As an example, feeding xgettext this file:

will not extract "hello" (a normal string) or any subsequent _() calls simply because a template string with / in it happened before:

Vaclav Slavik <vslavik>
Wed 03 May 2017 08:38:23 PM UTC, comment #4:

Ah, I see now, thanks for correcting me.

You mean to support the so-called "template strings" / "template literals":

Makes a lot of sense - with the limitation that the expressions inside braces should be limited to simple variable references.

Bruno Haible <haible>
Project Administrator
Wed 03 May 2017 07:09:44 PM UTC, comment #3:

(To be clear, the difference is the backticks)

Philip Chimento <ptomato>
Wed 03 May 2017 07:08:57 PM UTC, comment #2:

You might be misunderstanding my motivation for filing this bug report. Believe me I know the problems of format strings getting mangled by translators no matter the programming language, so that's not what the bug report was about

However, Javascript's interpolated strings are not supported in xgettext at all, even if you use only simple variable names or no interpolation at all:

echo '_(`hello`)' | xgettext - --language=javascript -o -

I think xgettext should recognize _(`hello`) as a string marked for translation, even if it is bad practice to use complicated interpolation expressions in it.

Philip Chimento <ptomato>
Wed 03 May 2017 03:15:21 PM UTC, comment #1:

I will close this as "Not a bug" and merely document that only simple variable names should be used in braces.

1) Translators are (in general) not programmers. You alienate them if you present them programming language expressions; even if all they have to do is to copy or preserve sich expressions.
2) A code refactoring (e.g. rename method 'toUpperCase()' to 'toUpper()') would change the string in the POT file, thus cause work to the translators.

Bruno Haible <haible>
Project Administrator
Tue 02 May 2017 11:14:55 PM UTC, original submission:

In the latest Javascript specification, the language has gained interpolated strings:

`${greeting}, ${planet.toUpperCase()}!`

They are delineated with backticks, and behave much like interpolated strings in other various languages.

Many widely used Javascript implementations either already support these strings, or are commonly used with preprocessors that perform the required code transformation for implementations without the feature.

It would be nice if xgettext understood these strings.

Philip Chimento <ptomato>



Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ueno (Posted a comment)
  • -email is unavailable- added by michaelgruber
  • -email is unavailable- added by trevinho (Updated the item)
  • -email is unavailable- added by piotrdrag
  • -email is unavailable- added by dmosberger (Posted a comment)
  • -email is unavailable- added by dmosberger (Voted in favor of this item)
  • -email is unavailable- added by brunoblookup (Posted a comment)
  • -email is unavailable- added by zumoshi (Voted in favor of this item)
  • -email is unavailable- added by vslavik (Voted in favor of this item)
  • -email is unavailable- added by erickwilder (Voted in favor of this item)
  • -email is unavailable- added by nterray (Voted in favor of this item)
  • -email is unavailable- added by nterray (Posted a comment)
  • -email is unavailable- added by weekens (Voted in favor of this item)
  • -email is unavailable- added by haible (Updated the item)
  • -email is unavailable- added by ptomato (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 405 encouragements so far.

    Only logged-in users can vote.




    Follow 18 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-13 michaelgruber Carbon-Copy- => Added michaelgruber
    2018-09-07 trevinho Attached File- => Added 0001-javascript-add-support-for-ES6-template-strings.patch, #44949
        Attached File- => Added 0002-javascript-do-not-translate-template-strings-wit-pla.patch, #44950
    2018-09-05 piotrdrag Carbon-Copy- => Added piotrdrag
    2018-07-25 dmosberger Carbon-Copy- => Added dmosberger
    2018-07-05 zumoshi Carbon-Copy- => Added zumoshi
    2018-01-31 vslavik Carbon-Copy- => Added vslavik
    2018-01-16 erickwilder Carbon-Copy- => Added erickwilder
    2018-01-05 haible Severity3 - Normal => 4 - Important
    2017-10-04 nterray Carbon-Copy- => Added nterray
    2017-10-03 weekens Carbon-Copy- => Added weekens
    2017-05-03 haible Severity1 - Wish => 3 - Normal
        StatusNot a Bug => None
        Assigned tohaible => None
        SummaryJavascript interpolated strings in xgettext => support Javascript template strings in xgettext
    2017-05-03 haible StatusNone => Not a Bug
        Assigned toNone => haible
    2017-05-03 haible Severity3 - Normal => 1 - Wish

    Back to the top

    Powered by Savane 3.4