And where do you use this?

I am using this in some code for a customer of mine for a birthday field.

If you're going to do this, you may aswell add all of them:

second(s), minute(s), hour(s), day(s), week(s), month(s), year(s)

Will be of great benefit for those who develop extensions that involve time

@brianteeman ?

It would probably also make sense to have them available on the back end too.

ask the team leader https://volunteers.joomla.org/teams/user-interface-text-working-group

It would seem logical to me that these strings exist in XX-xx.ini While we usually dont have strings that are not used you will see that we have all the month names etc

why not inches, centimeters, litres, gallons, etc...
singular and plural while we are there...
i can think of dozains others.
imho, let 3pd, if they need them, add whatever they need in their extensions

@infograf768 - If that's you're thinking, then you may aswell close this PR

If the core language library is only providing strings for what core actually uses, is it really that good? We have a lot of date processing functions in core, to me it makes sense that we would have strings in core supporting those as practical.

I do find it funny though the line is being drawn on adding two common strings when we still ask new translation teams to translate keys removed from core 5 years ago though...

@Hackwar please just add the same strings to the ini file in the admin as well and then we can merge this - the two files are supposed ti be in sync with each other

I don't have an issue with adding Day and Month. But we certainly have to draw a line somewhere, so I wouldn't add second(s), minute(s), hour(s), day(s), week(s), month(s), year(s). I'd say that would go to far.
The core file aren't meant to be a general "commonly used words"-file. It's the "words commonly used in core"-file 😄

Anyway, for 3.8 it will be to late as language freeze is in effect. 3.8.1 would be earliest.

As these new keys are not being used anywhere then language freeze is irrelevant

As these new keys are not being used anywhere then language freeze is irrelevant

Wrong. They are automatically added to crowdin and force TTs to review again that file.
We already have to let them know about the non-synced lib_joomla.ini. Enough for 3.8.0.

As these new keys are not being used anywhere then language freeze is irrelevant

They will be used in 3rd parties, that's the whole intention of this PR. 😄

we should re-think the whole process.... imho

@alikon You're not the first to say that, and some thoughts were already done 😄
For 4.0 that is something to consider, especially adding a "minimum version" tag to the language pack so newer packs can't be installed into "unsupported" outdated Joomla versions. But that also needs changes on the updateserver, and those changes have to wait till the packs are migrated to the new download site (at least I think so).

glad to know...
i hope in a next gsoc project we can leverage more on some dynamic/automated translation API

@alikon
automated translation with correct results does not exist, even for largely spoken languages.
it is 5% correct for only parts of phrases and at 90% ridiculous. the 5% remaining have made big scores on twitter.😂

I added the strings in the backend en-GB.ini. @brianteeman if those files should be at least somewhat in sync, then we failed pretty big there. Those files are everything but in sync....

en-GB.ini isn't supposed to be in sync. Only the en-GB.lib_joomla.ini one should be in sync.

I have tested this item ✅ successfully on 68f48d6

RTC

I have tested this item ✅ successfully on 68f48d6

I have tested this item ✅ successfully on 68f48d6