Custom profile fields are not very good with localization

[emanuele45]

Custom profile fields are "strict" on the language: for example the gender icon depends on the value of the field (i.e. the text displayed). There are two main problems here:

1. it's not possible to have localized fields,
2. when the text is changed, it requires to add also the corresponding CSS in order to fix the CSS classes that in the meantime have changed.

Point 1 could be lower priority since one language may be enough "for the time being". Point 2, though, is a bit more pressing, because it adds a burden to the user using the custom fields.

For point 2, what I would like to do is add a "key" associated to the value, this key will replace the "value" for all the technical uses (i.e. anything except the display of the actual text to the users in the template). Problems may be:

1. how to define the key in the admin panel,
2. regressions.

On top of that solution (at some point) we may be able to build a localization feature for the custom profile fields, but this may be for 2.0.

[live627]

I'd say the key can simply be col_name used internally to tie everything together as it is now. Then add a new field which acts as the displayed title. Boom, done, no need for CSS finagling or whatever.

[emanuele45]

Problem is that the column refers to the custom field, not the the value of the custom field... :-\

[Vekseid]

Is a key actually needed?

If it's basically multiple choice, then we can just test if the value is a valid variable, then call it from the standard localization config.

We could use that as a kind of hack until 2.0, anyway.

[emanuele45]

At the moment I'm not terribly concerned by supporting multiple languages at the same time. What I'm more concerned about is avoid this: https://www.elkarte.net/community/index.php?topic=5082.0

[Vekseid]

It would still fix that, though.

Making a key column has a lot of potential complications right now, whereas using the value as a basis for localization is pretty straightforward.

[emanuele45]

Yeah... though that doesn't entirely solve the issue (at best), because still the value will be exposed in the admin panel, and if, for any reason, a user changes it, he will lose translations and styles (if applied, of course). To me, binding the value to a $txt would be even more of a reason to have a key. Albeit that key could very well be just the index of the entry (0, 1, 2, etc.) preceded by the name of the custom field in the CSS, so for example for the gender could be: cust_gender_0, cust_gender_1, etc. leading to css classes like: .i-cust_gender_0 instead of .i-undisclosed .i-cust_gender_1instead of .i-male and so on. That would work without almost any change at all (except renaming some CSS classes in icons_svg.css).

[emanuele45]

The part fixable in 1.1.x is done, the rest is up for a "next version".