Hi guys,
We've recently had a couple loose threads around how to store strings in AST.
In particular:
- For editors, source of the string is more valuable than the AST of it
- For runtime, having a source of the string is helpful for error reporting
In result Stas suggested to try to parse simple strings into AST and then parse
them to complex strings only at runtime.
The result would be that an entity like this:
<foo "{{ n }} times">
would be stored as:
{$i: 'foo', $v: '{{ n }} times'}
instead of:
{$i: 'foo', $v: [{t: 'id', v: 'n'}, ' times']}
and then at runtime we would parse it again if '{{' is present, to generate
complex string.
Well, I gave it a try[0], and am not sure what to think about it.
First, the code is complex. I took some shortcuts (like, I ignore strings
inside a placeable, because we don't support them yet) but it still looks
fairly entangles.
Second, the performance is just slightly better than full complex string
parsing. I'm afraid that when we add runtime string parsing, the net result
will be a regression.
Third, it will get more complex when we start supporting strings in placeables.
I believe that we all agree that string expressions should not support
placeables, but they should support escapes...
That means that we will have cases like this:
<foo "Hello {{ $test["one\"andtwo\u1234"] }}">
That means that we need three variants of string parsers:
- simple string parser for values (parses only the string, unescapes only
string enclosing quotes)
- complex string parser (parses simple string into complex string, unescapes
unicode, and escaped placeables, potentially \n\t\r etc.)
- string expression parser (parses only the string, unescapes string enclosing
quotes and unicode)
Lastly, the change moves some of the parser time errors, to runtime errors.
With the current approach of parsing complex strings, this:
<foo "Hello {{ i`d }}">
produces parse time error. That means that our tools know it's a malformed
Entity and can report that, and we can also fall back at l10n-merge.
With this change, it will be a runtime error, because parser will happily parse
that into AST.
======================
Bottom line is, I think it's not worth it, unless you can give me more ideas on
what to do and how to make it work better.
One solution would be to pass an argument to the parser that would make the
getComplexString return a string instead of an array (but parse the whole thing
normally).
That would preserve the current performance, solve the problem for Matjaz
(editor would receive the string value as a string), keep the parse time errors.
It would not solve the runtime error reporting.
Would that work for you guys?
zb.
[0]
https://github.com/zbraniecki/l20n.js/compare/v3-features...zbraniecki:v3-simplestring
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
