Proper months localisation

[LazyBadger]

Well, my first idea was to send newmonth array to modifier by entries.tpl or config.inc.php, thats why. If we know all possible language arrays, better will be something like
...

I'm sure it's not better - we'll never can know all languages, more languages => more size of file, adding files for any missing locale require editing code, long switch will annoy and disturb "Sinn für Schönheit"
Replacement-hash as parameter is a Proper Way, I asked only where to store hashes (write 12 pair inside template for me seems as not technical and not engineering choice)

[Timbalu]

Its just a Smarty modifier for a certain case...
You can use the templates config.inc.php file to create you lang array there, assign it to smarty by

Code: Select all

$replace_langpairs = array(....)
$serendipity['smarty']->assign('newmonth', $replace_langpairs);

and call it

Code: Select all

{$entry.timestamp|@formatTime:DATE_FORMAT_ENTRY|localmonth:$newmonth}

and the modifier changes to

Code: Select all

function smarty_modifier_localmonth( $monthdate='', $newmonth, $lower=false )

without any switches and arrays only using the strtr replacement.
But this is sort of cosmetic...., while it is an individual workaround for PHPs "wrong?" strftime month names.

[LazyBadger]

Well, my motivation is not only solve my small annoyance with date, but to generate usable and correct solution at least for any s9y user or (at max degree) fr any Smarty-user

[Timbalu]

Yes, I understand you motivation.
But having a general solution would mean to put the replacement with all possible languages into a core function and change the output of $entry.timestamp to be pre-formatted. Everyone would have to change its old entries.tpl. I don't think Garvin would like to do this, as long as we don't know if this is a PHP bug or not. Regarding this, the best solution by now, is to have this modifier as simple and compact as possible and tell the people to use it in case of using a language with this sort of wrong output.

[LazyBadger]

I newer said and even never think about changing core, and always said about free to use additional modifier - inside or outside s9y
"General" means only - "none patching in codefor new language's dates"

Regarding this, the best solution by now is to have this modifier as simple and compact as possible and tell the people to use it in case of using a language with this sort of wrong outout.

Yes, and I totally agree with this point. And in order to have modifier small and universal and usable even for not-so-technical-savvy users I began to think about expanding the language files how it done now for URL-transliterations - for some languages too ($i18n_filename_from + $i18n_filename_to). Translator know rules of casing dates, he can prepare this hash and good day will be delivered to users automagically

[Timbalu]

Now you know the way to do, please go on and enhance the modifier, and give back how you proceed.
I myself would be interested in other peoples opinions, with further languages which may have this problem too.