freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <>
Subject The problem of "too human" text transformations
Date Wed, 30 May 2018 08:59:59 GMT
There's this old frequently requested built-in,
maybeTooLongText?truncate(n). Like "No space for such a long
title"?truncate(13) would give "No space...". The problem with these
is that there's no single algorithm for this that fits the need of
everyone. Like maybe the result should be "No space f...", or "No
space [...]", etc. This can even change depending on the current value
of the `locale` FreeMarker setting.

Now there's another similar wish, for "?title_case", which has the
same problem, plus it's much more locale dependent. See:

We do provide locale dependent functions, like number and date
formatting. This is pretty much an FM tradition, to treat non-English
users as equals (well, except that the keywords aren't localizable).
However, we push those tasks to the Java platform. But it doesn't
support title case (as far as I know). Besides there can be different
preferences even inside the same country, just as with ?truncate.

So, it's acceptable to chicken out ;) saying that none of the above
has a widely accepted default, so the correct solution is letting the
user solve this. But I think in practice what happens is that people
need the functionality (especially ?truncate), and then has to come up
with some ad-hoc solution on the spot, which will be almost always
worse than the default we could provide. So we might as well just
provide some decent default, sparing time for lot of users. Then, then
if they are particular about the algorithm (which is certainly rare
nowadays), let them plug their own via the Configurable API. So there
would be something like
cfg.setTruncateImplementation(localToImplementationMap), where the
parameter maps locale-s to Java functions and defines a fallback
function. (I haven't worked out the API details, as you can see.)

What do you think?

 Daniel Dekany

View raw message