Eemeli Aro
Eemeli Aro
That could work. This query seems to get pretty close, but still includes some false positives due to the other spacing changes: ```sql select t.id, replace(t.string, E'\n', '¶') as ts,...
> Asking a possibly obvious question: if you input a translation with a non-breaking space in Android projects, it gets serialized and read back correctly with the current code (guessing...
As a first step, I'm working on replacing at least the serialisers (and potentially the parsers) with their moz.l10n equivalents, without touching the database. The likely next step after that...
Following mozilla/moz-l10n#65, my planned next step here is to replace the resource parsers with moz.l10n tooling, while still keeping the data model as it is.
I think it's way too late to introduce this syntax change for consideration, and I do not think we should consider this for LDML 45. As an implementer, I'd like...
> I'd be curious how markup is currently parsed by implementations? I parse markup [together](https://github.com/messageformat/messageformat/blob/c53d954114f9da08822f2ee4cfa884363fa9b565/packages/mf2-messageformat/src/data-model/parse.ts#L215) with expressions. Because the constructions are syntactically so similar, it's easier to have just one...
> `#` is not a sigil on the markup, it is part of the `{` prefix. That's not our syntax, though? As you note in the first post on this...
> Why do you assume that the `.match` has no declarational effect? Because we never say that it has any such effect. I could imagine such an approach providing a...
> @eemeli noted: > > > According to our current language, selector and placeholder expressions do not modify their operand beyond themselves. > > I can't find where we do...
Let's say you're right, and our current text does allow for a `.match` expression to modify its operand so that information is carried from selector expressions to placeholders. So with...