Re: [Ktechlab-devel] translatable strings in simulator code

[Zoltan P. <zol...@gm...>]

Hi,


2010/11/22 Julian Bäume <ju...@sv...>:
> 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.
>

First of all, you're right. I was just running in find-replace mode on
the source code. Probably the names in the simulator should be removed
completely. I was just afraid to not to break the simulator in a
subtle way.

> 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).
>

Looks good :)

> 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.
>

If it knows about the properties of the component (gets them from the
currently selected class), then it's perfect. Also note that we need a
way to load/save the value of the properties in circuit files,
hopefully without duplicating definitions between the simulator and
the GUI.

> bye for now
> julian
>

 Have a nice day,
  Zoltan


> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> Ktechlab-devel mailing list
> Kte...@li...
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>
>