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:  400  
 
Category:  JavaScript Severity:  4 - Important
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

( Jump to the original submission)

Wed 25 Jul 2018 03:22:39 AM UTC, comment #8:

Likewise.

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:

Hello,

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?

Regards,
Nicolas

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":
http://stackoverflow.com/questions/27678052/what-is-the-usage-of-the-backtick-symbol-in-javascript
http://exploringjs.com/es6/ch_template-literals.html
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
https://docs.microsoft.com/en-us/scripting/javascript/advanced/template-strings-javascript

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.

Reasons:
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>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -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 400 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.3