Support null/undefined variables in selectors

[future2r]

A string based selector compares some specified values to the actual variable value. It would be very usefull to be able to specify a message if the variable is null, undefined or empty.

Maybe like this:

user = 
  { $user ->
    [] Your name is pretty short (empty string)
    ?[] You don't have a name (undefined)
    ![] You don't have a name (null)
    *[other] Your name is {$user}
}```

[stasm]

I've moved this to the spec repo, as we'd need to make a change to the syntax in order to make this work.

[alerque]

I agree the test for an empty string would be great. However is the difference between 'undefined' and 'null' really meaningful here? This will be hard to implement in some languages that don't even make such a distinction.

For example my Lua implementation would have a real hard time with this because 'undefined' variables are by definition nil. It is already enough of a pain using the reference fixtures that have nulls, but introducing null as a concept that should be determined based on the state of the value coming in would be complete nonsense.

[spookylukey]

There are also languages that don't have null, especially ML family.

[JohnnyJayJay]

I agree that this is a useful feature that should be added. To avoid conflicts and ambiguity among different languages, maybe it should be called "absent" and whether it's actually null, nil, undefined, Nothing or whatever would be implementation detail.

[alerque]

@JohnnyJayJay I don't think it matters what you call it, null is fine and a recognizable programming term even if it's called something different in another language. The point is the above proposal has two different entries, one for null and another for undefined. I think what I'm suggesting is that those two need to be consolidated into just one mode that covers both the case of nil values and undefined variables.

[JohnnyJayJay]

@alerque Yes I agree, most languages I know make no distinction there either. My point was that there should be one common name for it that each implementation may handle whatever way. It was rather meant to be a reply to the person above my comment

[SirNickolas]

1. I don’t think that localizers should be able to match against undefined. Undefined variables generally signal a bug in the program, and the programmer should be responsible for dealing with bugs, not the translator.
   Also, as has already been said, very few languages have two different concepts for null and undefined. While in JavaScript it could be implemented naturally, other languages would have to emulate it to be compatible with the spec.

2. I don’t think that localizers should be able to match against null either. Or, more precisely, that null should be included into the domain of Fluent’s variables. Null references in high-level languages have been addressed as a “billion-dollar mistake” by even their inventor. If null was an allowed value, it would uncontrollably pop up everywhere and cause either its ignorance by translators or unnecessary bloating of patterns with null-handling logic.

3. I doubt that matching against empty strings is really required. I agree, it looks innocent: every language that has strings supports empty ones and it would be counter-intuitive to prohibit developers to pass them to messages. However, using an empty string for indication of an absence of a value is not much different than using null for that purpose.

4. If a user doesn’t have a name, then they perhaps doesn’t have pretty much anything else. So it might be clearer to provide a $logged-in variable and check it instead (1/0 or yes/no; unfortunately, Fluent doesn’t have boolean type). Or even split the translation into two different messages.

[JohnnyJayJay]

I don’t think that localizers should be able to match against null either. Or, more precisely, that null should be included into the domain of Fluent’s variables. Null references in high-level languages have been addressed as a “billion-dollar mistake” by even their inventor. If null was an allowed value, it would uncontrollably pop up everywhere and cause either its ignorance by translators or unnecessary bloating of patterns with null-handling logic.

I disagree. There are situations where you want to say "this has no value" on purpose. The "billion dollar mistake" was about null references and their security and error vulnerabilities. The proposed concept of absence is far more abstract and has no such implications.

[Pike]

I'd argue that this falls into the bucket of https://github.com/projectfluent/fluent/wiki/Good-Practices-for-Developers#prefer-separate-messages-over-variants-for-ui-logic.

[future2r]

I'd argue that this falls into the bucket of https://github.com/projectfluent/fluent/wiki/Good-Practices-for-Developers#prefer-separate-messages-over-variants-for-ui-logic.

You clearly have a point here. Localization shouldn't replace program logic of course.

[serak]

the issue is logical but how do you even implement undefined and null in languages other than javascript ? lets say rust ?