> I think that also Portuguese and Spanish should be separated out - due to
dual encoding
Yes, I was thinking about that too.
> So, what solution do you suggest?
The file I sent you with the Czech language can be maintained in LED and
used in C after a ledc conversion as the other file I also sent you (at
least for now). This could be a downloadable link in the contributions page
in the IUP documentation. Applications that would like to use it just have
to include the .C file during the build and call the initialization
function plus IupSetLanguagePack.
But for pure Lua applications (that simply use the Lua interpreter) this
is not a good solution, we will need also a Lua version of that file that
can be loaded in run time. I have to think in a LED to Lua converter. Maybe
we can adapt ledc to do that. Of course that the C file could also be
compiled into a DLL and dynamically loaded by the interpreter.
Anyway there are a few tasks to improve this in the next version.
Best,
Scuri
2017-10-17 10:41 GMT-02:00 Jiří Klimeš <blue...@centrum.cz>:
> On Wed, 11 Oct 2017 19:42:58 -0300
> Antonio Scuri <antonio.sc...@gmail.com> wrote:
>
> > As far as the localization scheme is concerned, I kind of expected
> > that sed and awk is available in Windows too (as part of Cygwin or
> > Mingw). But if they are not a hard dependency, I would say the same
> > script can be coded in Windows as a batch script. (And called from
> > tecmakewin.mak - this is the makefile used in Windows, right?).
> > I looked at IupSetLanguagePack() function. It is a good
> > functionality. It might be used here. However, it won't help much. I
> > mean, the main selling points for the
> > change was:
> > 1. separate language strings from code
> > 2. use very simple text files (easy for translation), without any
> > code/syntax suger
> > 3. let the machines generate the code without the need for
> > manual maintenance
> > Using the LED file, would fulfill 1) and partly also 2).
> > But the files would have to be distributed and loaded at runtime,
> > which is not optimal.
> > When using ledc compiler, we have the same situation as in my
> > suggested solution,
> > i.e. there is a need to transform an input file to a output C source.
> >
> > I understand your points but I still don't think it is what we want
> > for IUP. The fact that we already have ledc/lua turns everything very
> > easy for our applications. But if you are talking about automatic
> > translations then clear text would make more sense. Although they are
> > still something that can be converted to LED or Lua, then used in
> > IupSetLanguagePack. Internally IUP won't have to change.
> >
>
> Well, I guess we can use IupSetLanguagePack() instead of my glue code
> (that did basically the same - loop for a structure and added strings).
> And if you are opposing to the automatic generation, we could write the
> strings directly to C file as IupUser structure - (if it is sub-optimal
> from a translator point of view).
>
> My main objective was adding the Czech language. And then seeing that
> doing it is not scalable, I realized that the localization should be
> changed so that adding a new translation is easy and without touching
> the code.
>
> So, what solution do you suggest?
>
> Best regards,
> blueowl
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
