id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
84	Making translators' lives easier (almost copy & paste from my post at edg@ecomstation.nl)	guest	Eugene Romanenko	"[ 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.
"	enhancement	closed	minor	1.4.0	Lucide Core	1.0 Beta 3	wontfix	easier translation