freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taher Alkhateeb <>
Subject Re: The problem of "too human" text transformations
Date Wed, 30 May 2018 12:50:53 GMT
I'm not a subject matter expert here, but I always thought sensible
defaults with the ability to override using configuration is a wise
move because you appeal to many people out of the box and then allow
minority to also not feel locked out when they need to override. Also,
as a general rule, I found from the projects we worked on that
internationalization is always a challenge, but you can also resolve
that with the same solution (sensible defaults with configuration
overrides); then you simply let the community adopt and improve the
code for non-English parts.

Of course then the challenge becomes, what's a sensible default? I
wish I had a dollar every time I asked that! I'd favor simplicity
where possible. In your example above maybe "No space f..." is the
simplest, and then people can get fancy if they want to?

My 2 cents, sorry for the noise :)

On Wed, May 30, 2018 at 11:59 AM, Daniel Dekany <> wrote:
> 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?
> --
> Thanks,
>  Daniel Dekany

View raw message