taoensso / tower

i18n & L10n library for Clojure/Script
https://www.taoensso.com/tower
Eclipse Public License 1.0
278 stars 24 forks source link

Maximum text size (hint for translator) and entity property texts #61

Closed obeah closed 9 years ago

obeah commented 9 years ago

Hi,

Is it possible possible to achieve the following with current functionality:

  1. Assuming there is some UI tool for translation: developer adds a new text that is used as a button caption. Due to UI layout restrictions he wants to enforce that text is not longer than 20 symbols in any language. So UI tool should be able to read this restriction from data and limit number of symbols in text field
  2. Managing different types of texts for entity properties. E.g. entity Person has 2 properties: first-name, last-name. These properties sometimes displayed on the form, sometimes in the table/grid. Also when user selects the field in UI the hint/description is shown in the status bar. So we have 3 types of texts for the property. In the ideal solution it should be possible to associate all 3 texts with 1 key and let the caller decide which text to use depending on context. Already mentioned imaginary UI tool would also enforce some global length restriction on these 3 types of texts. E.g. grid - 20, form - 40, description - 150. So translator would have to come up with some reasonable abbreviation for grid text if necessary. I think it can be achieved now by introducing some reserved suffixed for keywords, like :last-name-grid, :last-name-form. But maybe there is a better solution since the one I suggested has some disadvantages.

Thanks

ptaoussanis commented 9 years ago

Hi there,

  1. You can add a note for translators to please keep <=20 symbols. There's no out-the-box way of enforcing a limit, but since dictionaries are just Clojure data structures, it'd be easy enough to apply any kind of limits you'd like.
  2. Not sure I really understood this one, but it does sound like you'll just want different translation keys. So something like :last-name-grid, :last-name-form or like {:last-name {:grid _ :form _}} (i.e. you can namespace the key variants if you like).

Hope that helps! Cheers :-)

obeah commented 9 years ago

Hi Peter,

Thank you for prompt answer. This questions come from prototyping possible re-implementation in clojure of the quite large system with (tens of) thousands of translatable texts and thousands of entity properties. I understand now, that I'll have to implement own solution but below are more detailed explanations in case you decide sometimes in the future to extend the library in order to support (some of) these requirements.

  1. What I meant is that some UI translation tool reads data structure and enforces limit on the level of edit field where translator enters his text. My question is if it is possible to add this kind of (meta-)data about the text to current data structure. Another similar example of such meta-data: some kind of comment/hint from developer to translator for some ambiguous text. Again, translator will not see the maps defined in clojure. He will just have an URL to translation UI where he has to translate all texts added/changed since last translation. So these meta data (size limit, hint/comment) has to be somehow associated with (some) texts and will influence translator's UI
  2. Different keys are possible but makes such texts definition more verbose and more difficult to maintain. If I know that in my system every entity property will always have 3 associated texts, then I'd prefer to define it like {:last-name ["LN" "Last name" "Enter last name of the person"]} I understand that this requirement may seem quite specific (though it is almost exactly the way how such property texts are defined in the largest ERP software).

Thanks

ptaoussanis commented 9 years ago

(1) My question is if it is possible to add this kind of (meta-)data about the text to current data structure.

There's support to add arbitrary comments to a key to help let translators know about any non-obvious context, limits/requirements, etc. (see the _comment_ key in the README example my-tconfig). Note that you'll need a tool which can use this info.

(2) If I know that in my system every entity property will always have 3 associated texts, then I'd prefer to define it like

You'd still need some way of identifying individual elements / translation keys. If you want to always identify by order and only order, you could do something like {:my-translation-key {:1 _ :2 _ :3 _}}. Not sure how that'd be more difficult to maintain, but it's possible I'm missing something (?).

Hope that helps, cheers! :-)