Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add strings for day and month to en-GB.ini #17887

Merged
merged 2 commits into from Sep 25, 2017
Merged

Conversation

@Hackwar
Copy link
Member

@Hackwar Hackwar commented Sep 6, 2017

We have a string for Year (JYEAR) in en-GB.ini, but not for month and day. This is just to make this consistent.

@infograf768
Copy link
Member

@infograf768 infograf768 commented Sep 6, 2017

And where do you use this?

@Hackwar
Copy link
Member Author

@Hackwar Hackwar commented Sep 6, 2017

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

@C-Lodder
Copy link
Member

@C-Lodder C-Lodder commented Sep 6, 2017

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 ?

@laoneo
Copy link
Member

@laoneo laoneo commented Sep 6, 2017

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

@brianteeman
Copy link
Member

@brianteeman brianteeman commented Sep 6, 2017

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

@infograf768
Copy link
Member

@infograf768 infograf768 commented Sep 6, 2017

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

@C-Lodder
Copy link
Member

@C-Lodder C-Lodder commented Sep 6, 2017

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

@mbabker
Copy link
Contributor

@mbabker mbabker commented Sep 6, 2017

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...

@brianteeman
Copy link
Member

@brianteeman brianteeman commented Sep 6, 2017

@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

@Bakual
Copy link
Contributor

@Bakual Bakual commented Sep 6, 2017

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.

@brianteeman
Copy link
Member

@brianteeman brianteeman commented Sep 6, 2017

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

@infograf768
Copy link
Member

@infograf768 infograf768 commented Sep 6, 2017

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.

@Bakual
Copy link
Contributor

@Bakual Bakual commented Sep 6, 2017

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. 😄

@alikon
Copy link
Contributor

@alikon alikon commented Sep 6, 2017

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

@Bakual
Copy link
Contributor

@Bakual Bakual commented Sep 6, 2017

@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).

@alikon
Copy link
Contributor

@alikon alikon commented Sep 6, 2017

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

@infograf768
Copy link
Member

@infograf768 infograf768 commented Sep 6, 2017

@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.😂

@Hackwar
Copy link
Member Author

@Hackwar Hackwar commented Sep 7, 2017

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....

@Bakual
Copy link
Contributor

@Bakual Bakual commented Sep 7, 2017

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

@brianteeman
Copy link
Member

@brianteeman brianteeman commented Sep 8, 2017

I have tested this item successfully on 68f48d6


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17887.

@wilsonge
Copy link
Contributor

@wilsonge wilsonge commented Sep 9, 2017

RTC


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17887.

@wilsonge
Copy link
Contributor

@wilsonge wilsonge commented Sep 9, 2017

I have tested this item successfully on 68f48d6


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/17887.

@brianteeman brianteeman added this to the Joomla 3.8.1 milestone Sep 19, 2017
@mbabker mbabker merged commit bfad4c1 into joomla:staging Sep 25, 2017
5 checks passed
5 checks passed
JTracker/HumanTestResults Human Test Results: 2 Successful 0 Failed.
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/drone/pr the build was successful
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
hound No violations found. Woof!
@Hackwar Hackwar deleted the Hackwar:patch-21 branch Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

10 participants