On Mon, 02 Oct 2017 12:55:55 +0200 <[email protected]> wrote: Hello Antonio,
would you please comment on the localization changes. My main points are: 1. Czech localization could be committed right away (no structure change to the current code) 2. Localization structure change I think that the approach with generated C files from a simple text translation file is a viable solution and the Windows part could be resolved using a batch script. (Anyway, the best solution would be using a standard localization tool, such as a gettext. gettext seems to be available for Windows too https://www.gnu.org/software/gettext/FAQ.html) I am sorry for the formatting issues of my previous mail (was using a web interface that screwed it up). So, here are my replies again with fixed formatting: ------ > First of all thank you for your contribution. > About 1) and 3) The first commit is just the Czech localization in the current scheme (similar to the Spanish one). It doesn't bring any structure changes. I guess it could be committed right away (before the other change is decided). > Large scale modifications in IUP code will be more effective if we > work together. Your modifications are interesting but I can not use > it. They add a dependency to Linux tools to the Makefile that directly > affect the Windows build. > I have an alternative that is more IUP friendly. The > IupSetLanguagePack function accepts a IupUser element that can contain > the string translations. This can be stored in a LED, Lua or C files. > And directly loaded by IUP, no need for external tools. But we didn't > have an fully complete example. So I downloaded your CZECH lang file > and converted to the LED format. Notice that LED and Lua can also be > converted to C files to embed in the application code. Attached the > CZECH utf8 file in LED and C format. Please take a look. As far as the localization scheme is concerned, I kind of expected that sed and awk are 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 sugar 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 an output C-source. So, I think that having a script that is called from make is a good solution. The question is what tool/language to use. Dual awk (unixes) and batch (Windows) could work fine. Or use a Lua script? Is Lua currently required or not? > About 2) Unfortunately we used "box" when we mean "frame", but for > coherence with the attribute names, we have to maintain the name > "box" where we used. The Spanish translation was actually incorrect, > when it used "cuadro". So there is no need for another definition for > now. I am afraid I don't understand what you mean by "coherence". I thought that IUP_* variables are not exposed in API and can be easily changed. Actually, the names are quite generic and that might lead to their usage for ambiguous stuff. It seems to me that e.g. plot marks would be better named as IUP_PLOT_MARK_CIRCLE, IUP_PLOT_MARK_BOX, .... Also, IUP_CANCEL would be better as IUP_BUTTON_CANCEL, etc. As for IUP_BOX, it appears in two places. When I edit a plot, I can see an awkward description in one of the places (either as plot mark, or frame around the plot). > About the bug-fixes, I committed all of them. Thanks. Thanks for that. It seems to me that you may copy the changes manually, because there are not the original commit messages (they contain useful info sometimes). Note that it is possible to download github commits by adding ".patch" to the URL ([1]). Then the patch could be easily added to SVN. But I don't know whether there is a tool to also include original commit message, or it has to be added manually. [1] https://stackoverflow.com/questions/21903805/how-to-download-a-single-commit-diff-from-github > Regarding the GIT, we are a very small team, so keeping a mirror is > not in our plans. I know it is more popular, but for now we are going > to keep just the SVN. But feel free to mirror it anywhere. If I recall > right there is already some mirror around, can't remember where. > I tried the issue tracker in the past, but it was so much work for us > with not much benefit that I give up. So our discussion tool is this > email list. Or you can send email directly to me. I don't know sourceforge much, but I understand that it could be an administrative overhead for you. As for the git mirrors, they are e.g. on github under svn2github account: https://github.com/svn2github/imtoolkit-im https://github.com/svn2github/canvasdraw-cd https://github.com/svn2github/iup-github I use their forks in my blueowl04 account to be able to commit to them. ------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/iup-users
