Repository navigation
Support null/undefined variables in selectors #310
Description
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}
}```
Activity
stasm commentedon Apr 7, 2020
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 commentedon Apr 9, 2020
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 introducingnullas a concept that should be determined based on the state of the value coming in would be complete nonsense.spookylukey commentedon Apr 9, 2020
There are also languages that don't have null, especially ML family.
JohnnyJayJay commentedon Apr 12, 2020
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,Nothingor whatever would be implementation detail.alerque commentedon Apr 12, 2020
@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 commentedon Apr 12, 2020
@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 commentedon Apr 12, 2020
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
nullandundefined. While in JavaScript it could be implemented naturally, other languages would have to emulate it to be compatible with the spec.I don’t think that localizers should be able to match against
nulleither. Or, more precisely, thatnullshould 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. Ifnullwas 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 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
nullfor that purpose.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-invariable and check it instead (1/0oryes/no; unfortunately, Fluent doesn’t have boolean type). Or even split the translation into two different messages.JohnnyJayJay commentedon Apr 12, 2020
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 commentedon Apr 12, 2020
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 commentedon Apr 15, 2020
You clearly have a point here. Localization shouldn't replace program logic of course.
serak commentedon Sep 22, 2020
the issue is logical but how do you even implement
undefinedandnullin languages other than javascript ? lets say rust ?lolbinarycat commentedon Mar 3, 2025
@serak rust has
Option, it can handle nullable types just fine, you just have to explicitly say "this might not have a value", instead of everything being implicitly nullable.