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 <[email protected]> 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: > > https://issues.apache.org/jira/browse/FREEMARKER-97 > > 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 >
