Grails

<g:select> tag to allow using optionValue with valueMessagePrefix for resolving i18n messages

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.0.3
  • Fix Version/s: None
  • Component/s: TagLib
  • Labels:
    None

Description

The current implementation of <g:select> tag allow the generation of i18n message in the body of the <option> tags from the concatenation of valueMessagePrefix and optionKey. This makes the programmer having to use message.properties i18n string codes like: book.1, book.2 because the <g:select> optionKey attribute is often an ID.

The idea here is to make <g:select> use the optionValue with the valueMessagePrefix to produce i18n string code like: plan.all, plan.nothing, plan.other

Example of when its needed:
class Plan {
String name
}

where plan.name is a string to be resolved.
The Plans are statically stored in the database and won't be modified dynamically. We want the name of the plans to be translated in many languages and want to use the grails i18n messages feature.
That's why it is needed to resolve a given prefix like 'plan', to every plan.name in a collection in the <g:select> tag.

Thanks

Pierre Delagrave

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Marcos Silva Pereira added a comment -

What about plan names like "Hi, I'm a plan name". What must be the properties key in message.properties? This is why Grails use id instead of optionValue.

Show
Marcos Silva Pereira added a comment - What about plan names like "Hi, I'm a plan name". What must be the properties key in message.properties? This is why Grails use id instead of optionValue.
Hide
Permalink
Ken T added a comment -

I don't think I understand the comment above. I can understand that there might be plan names that don't work, but I don't think that detracts from this important use case. I am doing something very similar to the person that entered this bug. The database entries are controlled by admin and will always match values in the message.properties file, but for ease of translation, and simply to make the file easier to understand, I don't want to use:

category.1=Sports Car

I would rather use:

category.sportscar=Sports Car

This makes it easier to understand what is desired and will reduce errors in translation.

Show
Ken T added a comment - I don't think I understand the comment above. I can understand that there might be plan names that don't work, but I don't think that detracts from this important use case. I am doing something very similar to the person that entered this bug. The database entries are controlled by admin and will always match values in the message.properties file, but for ease of translation, and simply to make the file easier to understand, I don't want to use: category.1=Sports Car I would rather use: category.sportscar=Sports Car This makes it easier to understand what is desired and will reduce errors in translation.
Hide
Permalink
Graeme Rocher added a comment -

There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3

for 1.2 final only issues considered blocking will now be fixed

Show
Graeme Rocher added a comment - There is no scope / time to resolve these remaining lower priority issues for 1.2 so moving to 1.3 for 1.2 final only issues considered blocking will now be fixed
Hide
Permalink
Fabian Necci added a comment - - edited

A workaround for this could be:

<g:select from="${plans}" optionKey="id" optionValue="${{g.message([code:'plan.'+it.name])}}">
Show
Fabian Necci added a comment - - edited A workaround for this could be: <g:select from="${plans}" optionKey="id" optionValue="${{g.message([code:'plan.'+it.name])}}">

People

  • Assignee:
    Unassigned
    Reporter:
    Pierre Delagrave
Vote (6)
Watch (7)

Dates

  • Created:
    Updated:
    Last Reviewed: