Please use attribute 'value' instead of content in select options

[vyt@…]

Now isn't possible to override label for select options (<option label="custom label">value</option> not works).

<option value="value">custom value</option> work fine.

Patch for macros.cs attached.

[Christopher Lenz]

You'll have to explain ;-)

Your patch AFAICT uses the same string for the value attribute and the content text of the <option> element, so it is redundant.

What exactly are you trying to customize here?

[Emmanuel Blot]

I've been in the same trouble, I thought I logged a request for enhancement for it, but I obviously forgot.

In other to localize Trac, we need a way to keep the values used by the engine unmodified, but change the items display to the user.

For <select> tags, we need to use <option value="engine">display value</option> syntax. Obviously, both values are different. I'm using an associative array to for the translation in the french translation (see TracTermsFr):

Something like (I forgot the exact syntax): <option value="<?cs var:field.value ?>"><?cs var:translate[field.value] ?></option>

That would be nice if all template files were providing the dual syntax, so that translation is done in the Python engine rather than in the template files, in other words, something like: <option value="<?cs var:field.value ?>"><?cs var:field.dispvalue ?></option>

[vyt@…]

I customize possibility for css selection based on ticket type value, and make easily customization for translation. My macros.cs uses:

 <select size="1" id="<?cs var:name ?>" name="<?cs var:name ?>"><?cs
  if:optional ?><option></option><?cs /if ?><?cs
  each:option = options ?>
   <option<?cs if:option == selected ?> selected="selected"<?cs /if ?> value="<?cs 
     var:option ?>"><?cs if:option == 'defect' ?>defect in Russian<?cs 
     elif:option == 'enhancement' ?>Russian enhancement<?cs
     elif:option == 'task' ?>Russian task<?cs
     else ?><?cs var:option ?><?cs /if ?></option><?cs
  /each ?>
 </select>

[vyt@…]

Emmanuel, can you show your <?cs var:translate[field.value] ?> function ?

[Emmanuel Blot]

Emmanuel, can you show your <?cs var:translate[field.value] ?> function ?

Have a look at: ​http://anciens.enib.fr/trac/public/wiki/TracFrench (in french, but you'll recognize the Trac interface)

Unfortunetly, translation is much more complex than it first seems, as the translation effort needs to be done on Python files as well as Clearsilver templates files (not to mention the Wiki pages themselves)

Let's take a sample file, ticket.cs

​http://anciens.enib.fr/trac/public/browser/tasks/trac/french-task/templates/ticket.cs, search for alt:translation

I'm using the alt syntax so that if a term has not been translated, the original english word is shown (instead of an error or a empty space).

The translation dictionnary is instanciated in the new translate() method in util.py, translated terms are loaded from a new section from the trac.ini configuration file.

The translation dictionnary is used by templates files as well as the Python engine. It is only used for "dynamic" words. "Static" words are still hardcoded in template and Python files.

I'm not that happy with this solution, but that is the best balance I found for now (knowing that I want to upgrade as easily as possible the translation to the future release of Trac, at least 0.9; and I do not want to invest to much effort translating Trac, as I believe a better solution will be designed from the ground up for translation in a next major release of Trac).

Either way, I think we should use the same way for translations (russian, portuguese, japanese, french, etc.) so if someone comes with a better solution, I'll be happy to follow it.

[vyt@…]

Thanks, I'll try this way. For what you use I18N_DICT in ​http://anciens.enib.fr/trac/public/browser/tasks/trac/french-task/trac/util.py if you use init_translations() in env.py ?

[Emmanuel Blot]

Ooops… for nothing, I missed a clean up.

The very first approach for translation was to hardcode the translated terms in util.py, but I do not like hardcoding values, so I moved the definition list to the trac.ini file … and I eventually forgot to remove it from this file. Thanks, I will remove it.

Be aware that there are some issues not resolved yet, mainly in the \query.cs\ template file - I need to work on the Javascript piece, but I not get a chance (lack of time) to work on it yet.

[vyt@…]

Also for future translators, look at ​http://anciens.enib.fr/trac/public/changeset/20

This is useful info about important changes, for example in main.py ;)

[vyt@…]

BTW, I make Russian translation of trunk r2315. Translation process available at ​http://vyt.vzljot.ru/trac_russian/timeline mostly in Russian.

[dserodio@…]

I added a patch to #2178 that changes field['options'] from a list to a dict with 'value' and 'label' keys, maybe it can close this ticket?

[Christian Boos]

A TracDev/Proposals/I18N topic.

[Christian Boos]

This issue doesn't seem to be pertinent anymore.

Can someone working on the i18n branch double check this?