Making translators' lives easier (almost copy & paste from my post at edg@ecomstation.nl)

[guest]

[ eComStation Developer Group ] I've just had a look at the source .lng file for Lucide translation.

It's short, it's plain text, it seems to be structured... but is NOT. It's easy to produce a translation for Lucide, but not so easy to produce a good one (perhaps some defects are inherited from NewView here?). What's wrong?

BTW, this is not intended to be a pun against Eugene Romanenko, but a constructive criticism that may be used by developers pf NLV-enabled apps to make translators' lives easier.

-Resource strings are split into groups starting with 'MENU_', 'TBHINT_' and the like. This is good, but strings within groups are hardly sorted, so you can't relate them to each other adequately (as you would if they resembled menu nesting, group boxes, etc. item order).

For example, to choose adequate mnemonics for user menus it is most convenient to have them in nested lists, ordered so that items in the list match the order in which they appear on the user menu. This happens most of the time, except that menu subgroups are shuffled around, or perhaps you are translating 'document' menu items and you suddenly find a subgroup from 'view'...

-Strings from each group can be related to strings in other groups. An obvious example is items-toolbar hint pairs. While it is very sensible to group menu items, it makes a little less sense to group hints, except perhaps for length comparison.

Parhaps a good solution would be a 2-column table for each app element (such as the user menu or dialog boxes) ordered by item (first column), with item-hint couples in each row. Of course, I mean user-editable columns; obviously there should be column for IDs, etc...

Just $0.02 more.

Regards, Alfredo.

[Lewis Rosenthal]

Milestone renamed

[Gregg Young]

Move closed tickets to completed milestone. Many of these were completed before 1.4.0