have you tested on another type of field?

Hmm, I confirm the issue.
What happens is that the value is obtained from the db where it is saved as the constant.
The translate_default JText is only applied when displaying from the xml.
No JText is applied when saving in the db.

No JText is applied when saving in the db.

Currently there is no configuration parameter to say if JText should be applied on values

• the above was discussed here: #12739

I understand that for frontend editting the users will not type language strings as values
but there are case that backend / advanced users will use a language string a value

@Denitz, @infograf768

Do you mean to save the translation for the string into the DB ?
or do you mean to save the language string and the apply JText on the value ? (e.g. usage of JText is enabled via a parameter)

This is a very special case where we should save the Default as translated in the db WHEN translate_default is true imho. At this stage, afaik, we do not have any example of the use of translate_default in core.

This is a very special case where we should save the Default as translated in the db WHEN translate_default is true imho. At this stage, afaik, we do not have any example of the use of translate_default in core.

I see, so it sounds to me that it if translate_default is true , the translation should be saved into the DB

hmm, after some thought, no.
i guess it should be translated when fetched from db.
i.e. in the form field, as well when the field is displayed, if it is, on the site.
@Denitz
Dennis, what you think?

Default value is not related to DB.
If a form doesn't have a value for a field, the default value (optionally translated) is displayed.
Empty field value can be stored but default is not applied anymore (right now we can't have empty field with default value because empty fields always display default value - it's not good).

Not sure I follow you.
I thought this issue concerned only the translation of the default value (Which is indeed an issue). It seems it mostly concerns for you the fact that we can't save a field as empty if a default is defined.
Isn't default designed for that? One could set default to "" and use a Hint for the field.

Empty field value can be stored but default is not applied anymore (right now we can't have empty field with default value because empty fields always display default value - it's not good).

If you need the ability to store an empty field, you can't use a default value for (hopefully) obvious reasons. It's the purpose of the default value to be shown when the field is empty ?
You can however use the placeholer (hint) feature in some cases. This would show a text in the field if it is empty, but it doesn't store it anywhere.

The purpose of default value is to pre-fill value in a form if field doesn't have a value. E.g. we create new item, there are no data for it, hence field doesn't have value and we display form with defaults.
Once a form is saved, fields have values (including empty values) and no defaults should be applied anymore.
Placeholder is not a value, it's information/description.

Your specification for the default value is different from the one used in Joomla.
Currently you can delete an existing value and save and get the default values back. That's actually an important behaviour in some areas (eg template colors). It's especially important when the field shouldn't have an empty value at all. Eg for Yes/No list fields.
Keep in mind that the code has the same default values applied as well in case the field is stored empty. So basically you can't have an empty value for fields where a default value is specified.

But in this case it is content / "data", it is not a configuration

my opinion is that it is wrong to treat this, as configuration parameters are treated

Maybe, but how are you going to differentiate between the two use cases? And how is the formfield going to know if it is showing the input field for the first time or not? It shouldn't be aware of that imho. But it's getting off topic here.

Maybe

Users and developers will complain about it, as being problematic

If it is showing the input field for the first time or not?

Actually this is a "must" implement ... fields should be made aware if record is new or not

But it's getting off topic here.
Yes

A good form API is by design ignorant to the data source and as such does NOT have an awareness of new versus existing. This is a distinction to be made in the MVC layer.

A good form API is by design ignorant to the data source and as such does NOT have an awareness of new versus existing.

yes, ok, but when you need to tell the field to only load the default value if the record is new,

How are you going to do it ?

Add some form javascript to clear default values from all fields that have it ?

That will be tricky and error-prone

A user will re-edit the record,

• will not notice the default value, and click save, and you have not intended data appearing,
• plus even if user notices the default values loading for existing records, re-clearing any fields from default value, every time any record is edited, is cumbersome

Effectively this forces any field that has a default value, to be "required" always having a value (and displaying in frontend a default value)

From UX perspective how does all this sound ?

I didn't say I have all the right solutions, but when it comes to being aware of data sources, a form API has no awareness of this or the data's state. All it knows is what is given to it (the form definition to set expectations and an optional data array to populate values from the original source, usually the database). So the actual form API (including fields) behave correctly with regards to not knowing if this is the user creating a record, editing the record for the first time or the hundredth time. Things that deal with the data's state IMO should be dealt with at the MVC layer where all the form building and processing are happening and this is where you'd work your magic to set these state based variables (however you do that isn't defined by our API, so ya what you'd do is probably inconsistent with what I'd do but that's a side effect of the API's structure).

Yes, this awareness of state is a common issue, but it's not something that should be "owned" by the form API itself. It should be dealt with at the integration layer, so more often than not the models in your MVC class chain.

The same argument goes for differentiating "types" of forms. JForm doesn't care about this. If you need fields to behave differently based on context, this is where you extend the form and/or fields through the integration layer (model or plugin events).

I see,

then the way to do it is to Fields Helper, to clear the default values of fields, if an existing record is edited, doing this before the Form is rendered, or at some other place

I doubt that is a good idea as it would change existing behaviour and thus isn't B/C.
If anything it would have to be an option that is disabled by default.

But then, in most cases you actually want it to behave the current way. For the rare special cases you could just do your own custom field for your extension and apply a different behaviour there.

I doubt that is a good idea as it would change existing behaviour and thus isn't B/C.

I was speaking of Fields Helper of custom fields,
the custom fields of J3.7 have not been released yet,
so no B/C break

I was not speaking of tampering with the behaviour in configuration forms, or in other plases, where Joomla form elements are used

the custom fields of J3.7 have not been released yet, so no B/C break

They sure should behave the same as regular fields. Remember they appear in the same place and the same form as the form fields from the XML files appear. There should be no difference in behaviour depending on how they ended up in the form.

i would be curious to know who implemented translate_default...

Ask and ye shall receive...

70befbe
https://developer.joomla.org/joomlacode-archive/issue-23711.html

That asks for a comment, but I resist ?

A better man than me :)

rotflol

In fact, the idea was nice. We never thought though that someone would leave the field empty. I wonder if we could solve that.

Imho, saving a translated default value is quite pointless. It means if a french guy saves the item, you have a french text in that field. If an english guy saves a similar item, the value would be saved (and shown) in english instead. When shown, the text can't be translated anymore since the already translated string is saved.
Imho it would make more sense to save the non-translated language key which then can be translated when showing to the user. But I likely miss the obvious use case here.

Articles have associations for their translations

For "text" / "textarea" fields, in every language user types TEXT into the field

• that is the language of the article

The text is then saved into the DB,

• in other associated articles the text of the fields is typed in the language of the article

Correct thing is that text / textarea field with default value

• shows the translation of the default value and then save the translation into the DB,
• this matches the behaviour of the user action that types values in the current language of the article

The above discussion is about text / textarea fields, for list-based fields (radio, checkboxes, list)

• there is no issue / no complication,

because we save the "Option value" into the DB and we display the "Option Text" after applying on it JText

this matches the behaviour of the user action that types values in the current language of the article

No, it doesn't match the behaviour. Because you can write a french article with an english UI (eg as an english guy) and the default value would be in english. He will have to delete the default value and put in his own translation (of the default value, if he needs that one). It only matches the behaviour if the UI is in the same language of the item.
On the other hand, if the language string key would be saved, the item could always show the correct translated text depending on the selected frontend language (if the value is passed through JText during display).

Translated default value can be stored in database once, but if user wants to keep the field empty - it should be allowed to store empty value.

I think that default value mostly defines non-translatable data like numbers or e.g. list of prohibited tags, default value should be only displayed if the field doesn't have stored data.

Translated default value can be stored in database once, but if user wants to keep the field empty - it should be allowed to store empty value.

I just talked about another subject discussed in latest posts here.

What you mention, was the original subject of this issue, (= be able to make field empty if it is not required)
which i agreed that it is proper behaviour from user perspective (regardless of existing API behaviour of fields).

But it seems not enough people here are convinced about it

Translated default value can be stored in database once, but if user wants to keep the field empty - it should be allowed to store empty value.

As said, already that's not possible the way we specify and use default values in Joomla. If you want to change that behavior, you would have to add a new option for it in the field. Not an easy task for sure:

• You have to adjust the field to somehow find out if the value was already stored or not. It isn't sufficient to just check if it's a new item or an edit, because the field could have been added in between (in an update or custom field).
• You need code in the Registry to differentiate if it is an unsafed value or an empty one, and then you need a new option there as well to tell it how it should apply the default value.

Keep in mind that currently (and probably for the last 10 years) it is expected behavior that a field with a default value can't be stored empty.

I hit this bug today

I have a field in a plugin that I want to use to display a message on the user registration form. As I know some sysadmins are lazy I thought I would give the field a default value. But I cant because the only thing that is displayed is the jtext key

For now I am using the hint field which does display the value and then in the view checking if the field is empty and if so then displying the hint.

Not a nice option

Set to "closed" on behalf of @jwaisner by The JTracker Application at issues.joomla.org/joomla-cms/12793

As this was indicated as expected behavior, closing.