Previous Entry Share Next Entry
Looking for a word
jducoeur wrote in querki_project
I really do owe this journal an update on all the stuff that's being added -- as expected, getting the wedding invites out the door (which is slowly starting, but only a few so far) is forcing me to add lots of new features. It's hectic but exciting, as we move from "Insufficient" to "Sufficient to do something real". (Following which we will progress to "Adequate to daily use" and, with any luck, "Good" in a few months.)

Here's one looking for a quick opinion, since I just discovered that I need to add it today. I need to add a function that returns the correct word -- singular or plural -- depending on how many things are in the received list. This is a pretty common problem, but to give the immediate example, say that an Invitee has an optional list of Children. I need to write something like:
Your [[Children -> __thingy("Child is", "Children are")]] ...
What is the right name for function _thingy(), which chooses the first parameter if the field is singular, the second if it is plural? (Note that parameters can be anything; I just suspect that text will be the most common usage.)

Obviously, I can do something horribly obvious like _singularOrPlural() if need be. But I have a feeling that there's a correct word out there, so suggestions would be welcomed...

  • 1

Some ideas, with links to wikipedia pages for traversing

Re: Some ideas, with links to wikipedia pages for traversing

I like quantify.

Re: Some ideas, with links to wikipedia pages for traversing

Interesting and relevant links -- thanks! The article on plurality, in particular, is a useful reminder that the nature of this probably is somewhat language-specific, and we may need more general solutions down the road.

The word plurality itself doesn't feel quite right -- it doesn't verb the parameters quite the way I expect. But it does suggest that mindways's suggestion of _pluralize() might be correct...

First thought: _pluralize().

Less verbose option to _singularOrPlural(): _oneOrMany().

And: It's obviously not relevant in this case, but for cases like "Last I knew, you had [0 children / 1 child / N children]" will the function default to plural for 0?

It's a good question, and I've been chewing on it. The thing is, the way Querki works, you're most often not even going to be displaying that *section* if the list is empty. (My experience is that this is the most common behaviour for most typical Querki use cases.)

So I dunno -- I think we're going to have to see how things work in practice. You may be correct that using the N version for 0 is usually correct, but I'm not sure yet...

I am quite confident that this aspect will be language-specific.

Quite likely, but I think we can cross that bridge when we come to it. A given Querki Space is usually going to be single-language -- while we will likely provide tools (eventually) for App authors to localize their Apps, I *suspect* that it's unrealistic to expect more than a handful of individual Spaces to do so. (I actually expect the number to be less than 0.1%.) So for the time being, I'm not too concerned.

More importantly, though, the way Querki typically mixes text and code means that we can have different functions, which get used in different localized text blocks as appropriate. So if you are building the localization for a language that uses the dual, you would invoke some sort of _dual() function in that case.

(In other words, Querki tends not to think in terms of raw strings, but in terms of mixed string/code templates. So you will usually be able to choose the right functions for the string you're constructing. That is *especially* going to be important to do localization well.)

So for now, I'm going to focus on making things as usable as possible for English. If we're terribly lucky, we'll have to revisit this problem for other languages down the line...

The thing is, the way Querki works, you're most often not even going to be displaying that *section* if the list is empty.

Hmm. In situations where I've dealt with singular/plural in the past, 0 has usually come up, due to a combination of two factors:
1. Dense layout. There's no "section" for [whatever]; it's a short snippet of text in a longer description / sentence.
2. Knowledge is not presumed absolute, so "0 of [whatever]" is more knowledge/data than no sentence at all (implying no knowledge).

That being said, you've obviously gone through use cases for Querki in far more detail than I have. :)

True, but I think you've made a good point here. There's little overhead in implementing things so that the plural form is used in the 0 case, so I may as well try that out, and we can see how it works...


Careful, though--in most languages pluralization can change the rest of the sentence. You may not care about i18n right now, but...

Also, is it at all possible to be 'smart' about this? Have a pre-built list of plurals, so qwerki "just works" if I write '$n child"?

It'd be a nice little 'wow' feature...

Maybe, but that's pretty advanced, and I'd have to think about what it would even mean.

The thing is, the word is fundamentally defined by context. Without a clear knowledge of the context -- the Property being referred to -- it's meaningless. So we need to say explicitly which context it's referring to, and that means that we can't get *much* more concise than the above phrasing without delving into some really hard and interesting problems.

There's an interesting concept lurking here, which might be worth exploring further down the line, having to do with the ambient context of a text block and how it might automatically affect the rendering of that text. (That is, there is a way to define the semantics of "a thing with children", and how that affects text, such that it could be mixed in as needed.) It's at *least* a year before we can possibly have enough cycles to explore that seriously, but I'm open to chewing on what the design might look like in practice...

Yep. That's why I'm thinking about it in terms of phrases instead of words, and I'm not spending *too* much time on this yet. There will probably be a thoroughly-correct answer that we should gradually design up, but for now I'm focused on what I can do today, which will suffice for some easy and common cases.

(This is one of those times where I wish y'all were actively on and using the system already -- I suspect folks need to play with it a bit to get a sense of how it really ticks, so we can have some really nitty-gritty discussions of what the ideal design would look like. *Sigh* -- soon...)

I like OneTwoManyLots(), but I'm kind of silly.

Seriously, though, I suspect their will be cases where the issue isn't just 1 v more, but finer grain control. No reason not to make this easily extensible, if in name only.

Quantify() seems like a good choice. Although, I worry that may end up with talking about someone's deca-grand-child at some point. =)

For this specific case, I'd probably go with _quantify(), though I can see _pluralize() too. (The philosophical problem I have with the latter is that "1 child" isn't plural...)

But (here comes the abstraction fairy to mess you up!), do you want something this specific? Do you also have _honorific() [1], which returns "Mr." or "Mrs." depending on gender? What does the first do about zero children and the latter do about doctors?

[1] Yeah, the name stinks because it's not a verb. This is a placeholder.

Are there more cases like these? At the core of it all, are you really looking for _choose(booleanTest, case1, case2, default)? I'm not saying you necessarily want to expose that to users like Aunt Martha, but I would hope that _quantify() and _honorific() and all their user-friendly friends are implemented through that common abstraction -- and if so, thinking about the necessary arguments for the common abstraction may inform the specific ones (and vice-versa).

Ask a simple question, get harder questions in return. That's how it works; sorry. :-)

Yeah, there's a philosophical issue here that I'm exploring, which you would probably appreciate -- maybe especially because it is rather thorny and interesting.

Querki is a platform, but a fairly weird and radical platform, and that leaves me trying to thread between two very different instincts. On the one hand, there's the engineer in me, trying to build things in optimally general, clean, flexible ways -- after all, that's how you do things in a platform. OTOH, there's the product manager, always pointing out that this is a platform very much aimed at man-in-the-street end users, who do not give a damn about perfect API design -- they want it to DWIM.

Add to that the fact that I am resource-constrained to a degree that is fairly comical, running what would traditionally be a 20-person company with 1.25 people, and I've wound up *deliberately* playing fast and loose with my abstraction level for now, sometimes playing "fair", building things from low-level tools, while at other times just hard-coding the DWIM.

When it seems appropriate and straightforward to build things in the general way, I'm doing so. But if that proves at all problematic -- especially if I decide that I just don't understand the general problem well enough yet -- I'm generally reaching for what seems to be the right "script-level" abstraction for the end user, on the theory that I can always refactor that later to be built on top of better lower-level tools once I have more examples.

So basically -- yeah, you are probably correct that there is a lower-level concept trying to break out here. I'm not at all sure what it *is* yet, though, so I'm holding off on trying to build it, and keeping my fingers crossed that I don't go in any truly bad directions in the meantime.

(And slowly beginning to ponder how I am, in the long term, going to tame what is likely to become a fairly humongous API. There is a lot of refactoring in my future, hopefully most of it before the first GA.)

Today's version of this challenge, BTW, is how to display the list of Things in the Space decently. It clearly wants to be shown as a hierarchy, but I don't yet have "Tree" as a data structure, and there are a number of challenges to deal with before I can add that. So I'm wrestling with whether to completely cheat on this and build it in Scala for now; whether to do something intermediate using recursive functions in Querki (an entertaining area to explore by itself); or whether to bite the bullet and introduce Trees, which require Tuples, which require Higher-Order Data Structures. The Engineer and the Product Manager are *totally* at war over the right way to tackle this...

  • 1

Log in

No account? Create an account