This is nice but i guess needs to be translatable so it can be run through Text::plural so that you can have mile vs miles, minute vs minutes etc etc

How is that possible?

For the rendering part, it would be possible, but the user would need to understand how plural strings work. You would have to enter a string like CUSTOM_UNIT. In the language override manager you then add the strings CUSTOM_UNIT_0, CUSTOM_UNIT_1 and CUSTOM_UNIT (for en-GB, other languages need different suffixes and maybe more or less strings) with the respective values.
When rendered, you pass the value and string through Text::plural. Eg Text::plural('CUSTOM_UNIT', 5);

edit: corrected my example which was wrong

It would be pretty pointless to do that and overly complex.

For english and german it's certainly not something that is needed often. We usually just write the plural.
I honestly don't know how such things are handled in other languages.

There are some things that can never be "easily" automated or translated. If someone really needs it then they can create an override but I doubt they ever will..

For the recipe example, it would be useful, in Danish at least.
Servings: 1 Adult
Preparation time: 1 Hour

Nice improvement btw. :)

Good luck writing the code to do that so it is usable - but I guess I will just have to make the changes in my own sites manually

I don't know. The code line is easy. Just pass the unit string through that Text::plural() function together with the value of the field. Or do I miss something?
If the user doesn't need that feature, the string will be rendered unchanged. If the user adds all the necessary language strings manually (eg in the language override manager) and knows what he does, it will be nicely translated. Same thing we do in other places where user input may be translatable.

This is a very nice idea. It would save the trouble of using layout overrides for the suffix.

It's also useful to have a "Prefix" option as well. Think of prices. You probably want to prepend a dollar icon, like: $200.

What would also be cool (another thing that I've been doing with custom layouts so far), is the ability to set a number_format for numeric values (so for text fields and for integer fields), allowing to set separators for thousands and decimals.

So for example, 365100 can be displayed as 365,100.
Or, 25.368274 (decimals) can be limited to 2 decimals as: 25.37.

Just throwing the idea out there as well. All stuff that I have been doing with layout overrides so far.

@AndySDH that is an interesting idea but off topic for this PR as it relates to just the integer field - this PR is for all fields.

Same thing we do in other places where user input may be translatable.

Can you point to an example please

Can you point to an example please

The title of a custom field is translatable, just a few lines above your added code.

It's not using the plural method in that case, but the concept should work same.

Updated code (and instructions above) for plurals

I have tested this item ✅ successfully on 0973b87

Test units, including plural. Worked fine.

Issue I just realized with the code. This breaks out of the "field-value" span, as it sits outside of it. Therefore breaking the style of the value part.

The suffix span should instead be part of the field-value span as well.

<span class="field-value">
	<?php echo $value; ?>
	<?php if ($showSuffix == 1) : ?>
		<span class="field-suffix"><?php echo htmlentities($suffix, ENT_QUOTES | ENT_IGNORE, 'UTF-8'); ?></span>
	<?php endif; ?>
</span>

Why? This way allows styling for the suffix independent of the value

a new field cannot break your layout!

Here is what I mean happens now:

But up to you. I can override the render.php and fix it for my sites. So that's no problem. But I might not be the only one that took this styling approach.

So you would just adjust your template as you would whenever you add something new.

Either overriding the JLayout or adjusting the CSS allows to fix this for you.
It always depends on your usecase, what structure would be better. For example if you have mixed fields, some with and some without units (or with different units) you can align the numbers better with Brians approach.

I have tested this item ✅ successfully on 0973b87

RTC

Just throwing out a couple of thoughts. Feel free to bash them.

• Do we need the "Show Suffix" option? I think we could simply have the "Suffix" field, and in the layout file simply check if it's empty or not. If it's empty, don't display it. If not empty, display it. No need for an extra toggle imho.

• And I think we could easily add a "Prefix" along with it, with the same exact logic as the suffix. So it would become something simple like:

Just my two cents anyway.

Do we need the "Show Suffix" option? I think we could simply have the "Suffix" field, and in the layout file simply check if it's empty or not. If it's empty, don't display it. If not empty, display it. No need for an extra toggle imho.

That's a good idea imho.

And I think we could easily add a "Prefix" along with it, with the same exact logic as the suffix. So it would become something simple like:

Personally I'd say you don't need both a prefix and a suffix. Or do you have a case where you'd use both at the same time? Otherwise the unit field could also be used before the value, nothing stops you from doing that in your override.

Feel free to submit your own pull request - I am not changing this

Feel free to submit your own pull request - I am not changing this

Well, I think this is good enough. As in, I don't think there is a urge to do more. Was just adding food for thought in case it resonated with you :)

RC is out. Language freeze is on.
This would be for next version.

This would be for next version.

Actually, since it's a new feature and thus goes into 3.10 (if new features are merged into that) or 4.0.

This would be for next version.

Actually, since it's a new feature and thus goes into 3.10 (if new features are merged into that) or 4.0.

I understand your concept of keeping new features for new "minor" versions but this approach just doesn't work. Because for some reason you self-impose yourself to only release minor versions up to a certain amount of numbers or only after a certain amount of months. Why can't you release them at a consistent pace instead of one like every year? Why can't there be a 3.11? a 3.12? a 3.34?

No, you can only go up to 3.10, meaning that if 3.10 happens to come out in 2 years, features can be finished and ready to go, but purposely withheld for months or even whole years (Yes, years!! I know it happened last year), no matter how small and simple they are, either (like this one).

It hinders Joomla from progressing and improving at a fast pace. Put features in when they are ready. So that more stuff can be done. Waiting delays progress. So imho: either change this policy or keep running behind.

So... I guess it's time for my sites to manually override this feature for 1 year before it makes it in an official release. I did this from November 2017 to November 2018 last year for another feature, I can do it again.

I agree this is a feature and not a bug fix so it should not be in a patch release BUT If the next minor release is only going to be made at the same time as joomla 4.0 then we have a problem as @wilsonge has stated that it will not be released until 2020

Because for some reason you self-impose yourself to only release minor versions up to a certain amount of numbers or only after a certain amount of months.

We decided to follow SemVer which mandates that new features require a new minor version.
There is no such rule that there can't be more minors per year. We could release minors every three months or whatever. It just needs someone willing to do the release work. That's the limiting ressource.

BUT If the next minor release is only going to be made at the same time as joomla 4.0 then we have a problem as @wilsonge has stated that it will not be released until 2020

I fully agree and that's why I asked the PD to revisit this and allow more minors within J3 until J4 is released. It was (unfortunately in my opinion) rejected so there is more focus on J4.

I fully agree and that's why I asked the PD to revisit this and allow more minors within J3 until J4 is released. It was (unfortunately in my opinion) rejected so there is more focus on J4.

Is that documented somewhere? If it is then the maintainers of the issue tracker should be made aware so that they can inform people when they submit a PR that it wont see the light of day until 2020 - so much for release often

Only what is written in the Meeting notes (https://volunteers.joomla.org/departments/production/reports/936-production-meeting-december-2018):

It was voted to reject this and stick to the current plan of having 3.10 as the bridge release for Joomla 4

I don't really have more informations. @wilsonge or any other PD member could explain it better.

ah - that is what in the missing sentence

Yeah, something is missing there ?

We could release minors every three months or whatever. It just needs someone willing to do the release work. That's the limiting ressource.

Eh, I see. Wish I had the skills to do it!

so that they can inform people when they submit a PR that it wont see the light of day until 2020 - so much for release often

I know right. So disheartening... :(

We could release minors every three months or whatever. It just needs someone willing to do the release work. That's the limiting ressource.

Eh, I see. Wish I had the skills to do it!

For the record, a minor release involves much more than just running the packaging script and publishing the release. Feature releases typically involve a larger number of project teams and resources, so a quick release cadence puts more work (and more burn out) on a higher number of project teams. Likewise, a quick release cadence alienates end users (even after having almost monthly releases for two years end users still groan that is too often). For a project the scale of Joomla, it is not feasible to push minor releases every time a feature is ready to ship to production.

For the record, a minor release involves much more than just running the packaging script and publishing the release. Feature releases typically involve a larger number of project teams and resources, so a quick release cadence puts more work (and more burn out) on a higher number of project teams. Likewise, a quick release cadence alienates end users (even after having almost monthly releases for two years end users still groan that is too often). For a project the scale of Joomla, it is not feasible to push minor releases every time a feature is ready to ship to production.

Well yeah, of course. I'm by no means saying there should be one every time there is a new feature ready, of course. But not even one release per year. There has to be a happy medium. Especially in this case where it's established for sure that it would take a full year for the next release.

One or two feature releases per year is that happy medium if you are one of the ones who are actively involved in the release processes (actual release publishing, marketing, documentation, translations, etc.). Anything more than that is asking for trouble, unless you are the CEO of a corporation using your company to force things to happen in your open source software to fulfill your for-profit organization's needs and investor promises.

Two would be an upgrade already. Especially now that with 3.10 being coupled with 4.0, it might get delayed etc. so there could potentially be 1.5+ year with no features getting merged... just because it has been decided that the number 3.10 "has" to be the last. No need to self-impose that restriction imho.
Oh well. Let's go back watching NXT UK Takeover.

3.9 was originally supposed to be the 4.0 bridge. Plans change.

Here's the issue from a pure code perspective. 4.0 is still 5 releases behind staging, this includes the entirety of 3.9. As long as features continue landing in 3.x, that just adds to the backlog of things that have to be merged forward to 4.0 (and then adapted to the 4.0 code). So moving forward on 3.x just makes it harder to move forward on 4.0 until 4.0 is caught up with 3.x (and it should never fall behind again once caught up). Sooner or later, you have to prioritize shipping 4.0 over continuing to ship 3.x feature releases, otherwise you continue to have the moving target of 4.0 with no realistic milestone in sight and continue splitting the few resources there are actually working on getting 4.0 shipped (outside of this elusive template team which seems to be the only 4.0 only group of people, most people working on 4.0 stuff are also working on 3.x maintenance). So sooner or later, it actually is a good thing that someone comes up and says "OK, 3.x feature releases are slowing down so we can actually ship 4.0 while PHP is still a relevant programming language".

3.9 was originally supposed to be the 4.0 bridge. Plans change.

Here's the issue from a pure code perspective. 4.0 is still 5 releases behind staging, this includes the entirety of 3.9. As long as features continue landing in 3.x, that just adds to the backlog of things that have to be merged forward to 4.0 (and then adapted to the 4.0 code). So moving forward on 3.x just makes it harder to move forward on 4.0 until 4.0 is caught up with 3.x (and it should never fall behind again once caught up). Sooner or later, you have to prioritize shipping 4.0 over continuing to ship 3.x feature releases, otherwise you continue to have the moving target of 4.0 with no realistic milestone in sight and continue splitting the few resources there are actually working on getting 4.0 shipped (outside of this elusive template team which seems to be the only 4.0 only group of people, most people working on 4.0 stuff are also working on 3.x maintenance). So sooner or later, it actually is a good thing that someone comes up and says "OK, 3.x feature releases are slowing down so we can actually ship 4.0 while PHP is still a relevant programming language".

LOL. It makes sense when put like that. Although I imagine that both bugfixes or features is stuff that needs to be merged forward anyway, so I assume it doesn't make much of a difference whether it's bugfix or a feature, especially if small like in this example. But I get it. I get this point of view too.
Well, I hope everything goes smoothly and you guys manage to catch up.

(This can probably be closed now by the way)

I have tested this item ✅ successfully on 0973b87

Tested with currency abbreviations. Worked well.

@wilsonge rebase on 4.0-dev ?

@HLeithner @wilsonge will this be accepted for J3 or should I refactor for J4

@brianteeman

Please migrate to j4 and please if its possible for you add post- and prefix maybe as selectbox.

I will rebase for j4 but i will not add the ability to only have either a prefix or a suffix
That places a limitation on the usage that is not required

Add both?

See my comment for inspiration :)
#23499 (comment)

yes i will do both but not have a switch

Once this is migrated to 4.0 branch this is approved (in case another maintainer gets to it before me)

Closed see #24232