News:

 

Topic: Localization  (Read 10730 times)

0 Members and 1 Guest are viewing this topic.

  • Posts: 496
  • Triangle
October 10, 2012, 08:47:18 am
Even though this is not a pressing matter at this moment, I guess any implementation of localization should be better done early in development. Nvil is far beyond the early development stage. I couldn't find any localization files in the Nvil related directories, so I guess there is none and it's hard coded somehow. But if localization is or will be planned, I suggest the localization files to be easily readable and editable. I've had good experiences with the way localization is done in UDK. The files are plain text and the content is formatted as a configuration file. So you've got sections and keys that get their values assigned.
So here's a trimmed down example how that could look like:

Code: [Select]
[UI]
OK=Accept
Cancel=Cancel
Enable=Enable

; ###Panels###
[MathSelection]
Title=Math Selection
CBoxSelection=Polygons with edges =
CBoxSelection=Polygons with edges !=
CBoxSelection=Polygons with edges <
ValueLabel=Value
ThresholdLabel=Equal Threshold
BooleanLabel=Boolean
CBoxBoolean=Replace
CBoxBoolean=Include
CBoxBoolean=Exclude

[ToolSearch]
Title=Tool Search

; ###Tools###
[ViewNavigationTools]
Title=View Navigation Tools
AlignAlongEdge=Align Along An Edge
BestFit=Best Fit

I think you'll get the idea. I don't know how Nvil is programmed, but if the ui elements, such as panels derive their variables from a parent class, they would also inherit the localization (e.g., OK-Buttons etc.), that if needed could be overloaded inside the localization file. Section names may be class names. Keys just need to be unique inside a section (as they are variable names inside of classes). In the above example, if there are multiple keys with the same name inside a section, these keys are dynamic arrays on the program side. The values then map to the appropriate indices.

But aside the programming style, however localization may be implemented, it bears certain benefits:
A higher potential to be spread around the world.
The community itself could make localization files for their respective language.
If someone isn't happy with the naming of tools, he or she could just change it to match the preferred naming known from other apps. It could then even be shared as part of the configuration, so people get more easily into modelling when switching from other applications.

The GUI in NVIL looks an awful lot like that of visual studio, so I guess there is already a way to do localization, too.

Seeing the amount of text in Nvil, if it's not already localization ready this can get a lot of work. But it may pay off.