Possibilities of using the date format

Hi

Quote from Aethior

because in Spanish the months can be written in upper and lower case (deppending use case).

Can you elaborate on this a little?

Generally speaking, date formatting beginning with WoltLab Suite 6.0 is delegated to PHP's / the web browsers Intl functionality that directly build on the relevant Unicode rules for the configured locale. The existing phrases are still available for compatibility (and possibly used in some places), but the majority of places should (hopefully) work correctly without doing anything fancy.

Hi

I now specifically checked ICU's (Intl's) behavior for Spanish and it uses the lowercase month for a “Month + Year” combination, e.g. “junio de 2023”. According to https://meta.wikimedia.org/wiki/Capitaliz…_of_month_names this appears to be correct, because contrary to e.g. Croatian the “unless title” note is missing.

Hi

Quote from Aethior

I'm going to start copying wcf.date.dateFormat and wcf.date.timeFormat in my Spanish language file.

Yeah as indicated in my first post, those two phrases are effectively considered legacy beginning with WoltLab Suite 6.0, as the heavy lifting is done by the internationalization APIs of PHP and the web browser. Instead of needing to specify a format string within the list of phrases, we can just ask the Unicode library to “Format a Date + Time as appropriate for Spanish” or “Format a Month + Year as appropriate for Spanish” and it will automatically choose something. In the long run this will also improve flexibility to use appropriate formats in the appropriate locations without adding a multitude of phrases that are not necessary for most languages and insufficient for the remaining languages. For example in the calendar the headings are correctly constructed by two separate parts, one bare month-name part and the year part. This breaks down for languages that put the year first (i.e. 2023 June instead of June 2023).

I've now specifically checked the Unicode data for Spanish (es). Both the regular variant:

icu/icu4c/source/data/locales/es.txt at a9f75708929a2bd14f941f36aa36a7189d76a389 · unicode-org/icu

The home of the ICU project source code. Contribute to unicode-org/icu development by creating an account on GitHub.

github.com

as well as the stand-alone variant (which is meant to be used for stuff like calendar headings):

icu/icu4c/source/data/locales/es.txt at a9f75708929a2bd14f941f36aa36a7189d76a389 · unicode-org/icu

The home of the ICU project source code. Contribute to unicode-org/icu development by creating an account on GitHub.

github.com

Use a lowercase month-name.

Spanish as spoken in Peru (es-PE) uses uppercase names in the stand-alone variant, though:

icu/icu4c/source/data/locales/es_PE.txt at a9f75708929a2bd14f941f36aa36a7189d76a389 · unicode-org/icu

The home of the ICU project source code. Contribute to unicode-org/icu development by creating an account on GitHub.

github.com

The calendar is not yet adjusted to use the Intl API for formatting, but I've opened a draft change internally to check how it works. By delegating to Intl, it will result in this (i.e. lowercase):

Is using a lowercase month name actually wrong here or is both upper- and lowercase acceptable for headlines? The former would imply that the official Unicode rules for Spanish would be incorrect

Hi

yeah, I totally follow your examples. However a headline / title is not technically a sentence. You wouldn't use a full-stop at the end either. As an example, I did a Google search for “Spanish Calendar” and found this: https://depositphotos.com/218974406/stoc…an-spanish.html. Of course this is not an official source, but it uses lowercased titles for both the month and weekday.

To give you an example of how the Intl API in PHP works, please have a look at this:

<?php
$locale = 'es_ES';
$date = new \DateTimeImmutable('2023-06-06');
$patternGenerator = new \IntlDatePatternGenerator($locale);

echo "Determine the formatting automatically\n";
var_dump($patternGenerator->getBestPattern('yMMMM'), \IntlDateFormatter::formatObject(
    $date,
    $patternGenerator->getBestPattern('yMMMM'),
    $locale
));
echo "\n";

echo "Determine the formatting automatically (stand-alone)\n";
var_dump($patternGenerator->getBestPattern('yLLLL'), \IntlDateFormatter::formatObject(
    $date,
    $patternGenerator->getBestPattern('yLLLL'),
    $locale
));
echo "\n";


echo "Bare year + month\n";
var_dump(\IntlDateFormatter::formatObject(
    $date,
    'y MMMM',
    $locale
));
echo "\n";

echo "Bare year + stand-alone month\n";
var_dump(\IntlDateFormatter::formatObject(
    $date,
    'y LLLL',
    $locale
));

At the very top I configure the es_ES locale for Spanish in Spain. I can then ask it to give me an appropriate format string for “year + written month” (yMMMM) and it will turn this into MMMM 'de' y thus automatically including the “de” preposition!

I've also tested the format for LLLL which is the standalone variant for the month name, but all variants return the month in lowercase.

Quote from Aethior

In any case, I must admit that I think it is too bold to say that we have discovered a bug in Unicode.

Yes, I would agree here. If this would actually be incorrect in the Unicode data files someone else must've discovered it before.

Hi

I did some research and came across this:

My understanding is that this is a limitation in expressiveness of the CLDR definition language. In the big table you can see for Spanish + Month + Ia/Ib that uppercase is correct as you suggested. It's marked as orange, indicating that “might handle by fixing data (depends on client usage of format vs standalone)”.

Unfortunately on our end we can't just uppercase the first character, because that would be incorrect for Danish and Finnish, which require months to always be lowercased even in headlines according to that table.

I think that delegating the work to the Intl API is no worse than the current capabilities and also preferable to introducing a multitude of different, but similar phrases that translators need to deal with. If the Unicode CLDR data is improved, it would automatically apply when upgrading PHP. Would you agree with my conclusion?

Hi

Quote from Aethior

I think I have caused you to receive a Spanish master class without expecting it.

Investigating this was most certainly more fun than quite of bit of other work. I always like being able to learn new stuff myself

Quote from Aethior

I also must confess that at times I have had doubts as to whether I was right.

Language as used “colloquially” often differs from what is technically correct and then there's also regional variations that can add to the confusion. It's the same for German. One of the reasons we delegate to Intl / Unicode's CLDR data beginning with WoltLab Suite 6.0 is that those are maintained by experts and already include rules for pretty much all relevant languages and are also able to handle the edge cases of the languages. For example in Russian the words for the months are different depending on whether you refer to the month without a day (“stand-alone”) or to a specific date within a month (“format”).

As you can see in the references I linked above, the CLDR data for Spanish (without including the country specific forms) is almost 3000 lines of information. German also has almost 3000 lines and Japanese clocks in at more than 4000 lines.

Quote from Aethior

This is a current limitation of Unicode, it is possible that it will be corrected or improved in the future.

Okay. I'll move this thread to the suggestion section then. I'll hopefully be able complete the proof of concept integration for WoltLab Suite 6.0. The calendar for Spanish would look like the above screenshot then.