Unable to handle translation strings containing escape sequences

[chrono-meter]

As the title says. When a translation string contains an escape sequence such as \n, tree-sitter does not provide a string representation, so the msgid will be expressed differently from the value expected by PHP or JavaScript.
I don't know if including escape sequences in translation strings is a widely used technique, but it's important to be aware that the output result may differ from what the library user expects.

Strings containing escape sequences become encapsed_string nodes, which contain string_content and escape_sequence nodes. It seems that only the raw value can be obtained from the escape_sequence node in question.
And it seems that we will probably not be able to obtain the correct value unless we implement PHP and JavaScript escape sequence processing.

[erikyo]

Thank you @chrono-meter for reporting that. I have successfully reproduced the issue regarding translation strings that include escape sequences (like \n).

Just as recap i'll break down here the issue:
The anomaly stems from the architectural division of labor between our tool and Tree-sitter, the underlying parser.

1. Structural vs. Semantic Parsing: Tree-sitter’s primary role is to create a precise Concrete Syntax Tree (CST). When it encounters a complex string literal—like "Hello\nWorld"—it intentionally separates the content into distinct nodes: string_content (for "Hello" and "World") and an escape_sequence node (for the raw characters \n).
2. The Missing Step: The parser delivers the raw source text for the escape_sequence (\n) but does not perform the semantic decoding (i.e., converting the two characters \ and n into a single Line Feed character, \u000A).
3. Incorrect Output: Because make-pot currently concatenates these raw node values, the resulting msgid in the .pot file contains the literal sequence (\n) instead of the correct, decoded character. For Internationalization (I18n), the msgid must represent the string's actual runtime value, not its source code representation.

And yes, you're right, to make it work we have to implement a filetype based decoding. Would you like me to assign the issue to you?

[chrono-meter]

There are several options.
First, I think an error or warning should be issued because the current version does not generate .pot file that users expect.

1. Create code to handle the escape sequence.
   While this is probably the preferable option, it seems questionable whether it is a realistic option considering the implementation cost and maintenance burden.

2. Handle the escape sequence through the PHP interpreter and JavaScript interpreter.
   This is easy to implement.
   Considering that this is a tool used by developers and the results parsed by the tree-sitter are passed to the interpreter, this is unlikely to be a problem, but the implementation itself could be treated as a vulnerability.