[Ktechlab-devel] translatable strings in simulator code

Julian Bäume julian at svg4all.de
Mon Nov 22 11:32:07 UTC 2010


moin,
I somehow dislike the idea of having translatable strings in the simulation 
code. AFAICS this is for now needed for the model parameters implemented for 
each component. I’d like to move that out of the Component-code. I‘m fine with 
having the definition in this class, though. Here is my proposal.

We move all translatable strings into the circuit-library I created (for 
sharing things between circuit-model, components and simulation) and just keep 
references in the simulation code. This means, we should avoid QStrings in 
this code, too. Instead QByteArray should be used. This has much less overhead 
than QString has and will lead to smaller memory footprint. (QByteArray is 
blain 8-bit ASCII, QString is 16-bit unicode and brings a lot of other 
features we don’t need at this place) So the Component code will look 
something like this:

m_properties.addProperty( QByteArray("resistance"), QVariant( (qreal) 5 ) );

I explicitly mentioned the types in here, you won’t need to write them in real 
code. So in real code it would look more like this:

m_properties.addProperty( "resistance", QVariant(5.0) );

The mapping into the translated strings is then done by another class in the 
library which reads the translated values from a config file. This config file 
will look like this:

[resistance]
name=Resistance
name[gb]=Resistance
name[de]=Widerstand
…
unit=Ω
unit[veryForaignCountry]=some arbitrary unit here

This will be more easy for translators and we could reuse translations for 
common properties. Technically this is a KConfig file, which is translatable 
with the KDE tools, so translators can use the tools they are used to. Also 
KDE ships parsers to easy access the values (it will also pick the right value 
according to the locale set by the user, so no extra code on our side is 
needed).

What do you think? Should we go this way? Then I’ll start implementing this 
config file and you can add new properties on demand. I’ll also provide the 
class that does the mapping from the "property-key" to the translated string 
from this config file.

btw. in my master branch, there is first code to provide a properties editor 
for components. Didn’t took long to write that. Still needs some love, but I 
can add more features to it, when the simulator gets ready. For now, I’m 
working on better interaction when editing circuit-files.

bye for now
julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20101122/fc8316fc/attachment.sig>


More information about the Ktechlab-devel mailing list