×

Notice

The forum is in read only mode.

Internationalization

  • The Never
  • Topic Author
  • Visitor
  • Visitor
18 years 8 months ago #261 by The Never
Internationalization was created by The Never
Ok, I've looked into the code for ASTK. Now, a good bit of it already uses locales and works. Obviously, the ASJOB window still lacks translations. Currently, I've added translations for ASJOB and updated the locales file. I'm going to continue work on adding translations for ALARMS/INFO/ etc...

My question is, does the community want this file set/patch ?
If the community is interested in this, I'm going to continue work on Eficas as well. A cursory glance at it's code suggests that NO such \"quick translation\" ability exists. I'm willing to work on adding locales support.

What will not be changed, is the handling of the *.comm files. However, a system will be setup to provide \"quick translation\" of the description when using Eficas, but we will not change the scripting/variable language or syntax. Currently this is because I'm assuming that these are tied to core parts of Aster.

What I mean is, for example, open Eficas and click Patrons -> poutre -> statlin_pou.comm.

Navigate down to the first Parametre and read the writing for the text at the bottom, on the right pane. Kinda difficult if you don't speak french. Damned if I can find an english translation anywhere in the code. So I propose leaving all Key elements to Aster that are French; in French, and changing descriptions/etc to use locale information. This way, it would basically be no different than learning the required variable names/parameters/etc for Femlab or anything else, even though the Key names themselves (such as MECA_STATIQUE) are French.

I could be off in my asumption as to how Aster handles the *.comm data, perhaps it could be done with locales, but I fear not.


What does the community think?
Should a internationalized port for the GUI/Tools/Comments/Descriptions/etc be started and the scripting/variable/etc be left in Native French?

Is anyone willing to assist me?
Lastly, if anyone from the Code_Aster team is seeing this, could we get the changes merged into the main branch? I really do not want to fork this, but I think this could be a major benefit for Linux/Unix Engineering, and perhaps with more language support, more Colleges and businesses would contribute to it's development.
  • The Never
  • Topic Author
  • Visitor
  • Visitor
18 years 7 months ago #274 by The Never
Replied by The Never on topic Re:Internationalization
Just an update in case anyone cares....
In Eficas I've setup basic gettext support and am working on getting some strings translated.

I'm thinking of adding this to the version I'm working on; on the fly language changing.
At startup of Eficas, right before Splash starts to load, I'm thinking of adding a quick language select. Then after load you'll be able to change languages on the fly from the Tools menu.

What does everyone that might possibly want this i18n setup for Eficas think?

It's gonna be a long road.....

-Jason
  • admin
  • Topic Author
  • Visitor
  • Visitor
18 years 7 months ago #281 by admin
Replied by admin on topic Re:Internationalization
Hi,

great news, I think your ideas are great and I am personnaly interested in translations for EFICAS as it seems to be the most difficult point in learning how to use Code-Aster for most users. I know that it is a lot of work to do to modify Eficas to add translations, so it mainly depends on how much time you can spend on that project, but I am sure that it will be usefull in the end!!

Keep on the good work and good luck!!
  • The Never
  • Topic Author
  • Visitor
  • Visitor
18 years 7 months ago #288 by The Never
Replied by The Never on topic Re:Internationalization
It's update time again....
I've been working on Eficas off and on; been busy with other things.

Anywho, Considering the default language is French, I'm going to leave it so. Right now, when the application is started, the splash screen comes up, does it's little loading deal and then waits for input. This input is a simple French/English button selection. After selecting the language it continues with displaying the main Eficas window.

I've got to spend a little time with the code to get the menu system to play nice. I've added the option already to change between French/English, but I'm having issues with getting \"File/Edit\" menu to accept the \"_()\" function for use with gettext. I've only spent about 15 minutes on the menu system, so, will have to study it a bit more.

The locales directory layout will follow the documentations suggested use. Further, I intend to place the locales directory in the root directory. Basically this...

Eficas-1.x.x (treated as root dir)
\
>Aster
\
>Editeur
\
>locales

And so on.

Now on to more pressing matters.
This is a copy/paste from the post I made in response to JMB on his translation of one document already..

--Copy--
Now the big question... how do we bring this all together?
Temporarily fork Eficas/Documentation to get everything localized and then dump it all back to the CA team?
Or do we join the CA team? (To be honest, I do not know how the CA team is put together, let alone if people are allowed to join with Dev access.)

Would a wiki be a good way to help move the documentation?

Eitherway, I think the community (apparently just 2-4 of us) that wants localized versions should come together with a common site/host/etc.
Perhaps CAELinux could be the place for this, as opposed to starting up something new.

Thoughts?
--End Copy--

I will continue working on this \"port/fork/whatever you want to call it\" of Eficas and it's documentation. Perhaps we could divide into teams if enough people came together for this.

-Jason
  • admin
  • Topic Author
  • Visitor
  • Visitor
18 years 7 months ago #291 by admin
Replied by admin on topic Re:Internationalization
Hi,

you are right, if we want to promote collaboration, a central place would be very usefull. I have to admit that for the next 2 to 3 months, I will be much too busy to contribute to translations, but what I can do is to setup a Wiki on CAELinux to facilitate group work and other contributions to the documentation.

The only drawback of Wiki websites is the time it takes to monitor the changes to prevent miss-use of the site.
To prevent \"deface\" and \"abuses\" by automatic scripts or stupid kids, I would like to start by protecting the write access with just one single password and anybody who wants to contribute can ask me for the access.

I will try to setup this wiki just after the release of beta 2 (end of next week).

Another idea would be to advertise a bit on our efforts in order to get some more help: for example, we can post on Code-Aster website about this project and see if anybody wants to join.

Anyway, I think that when we will have more or less finished this project, we will have to give a copy of our work to Code-Aster dev team so they can integrate these changes in the future releases and publish the documents on their website.

Keep on the good work folks!!
  • The Never
  • Topic Author
  • Visitor
  • Visitor
18 years 7 months ago #294 by The Never
Replied by The Never on topic Re:Internationalization
I understand that too busy thing. Always seems to be so much to do and yet never enough time to actually get anything done.

Yeah, I can see how the wiki being freely open would be an issue. Though it seems you've tackled that already by just allowing a few to edit/approve. Perhaps, if teams are setup, the team leads could have that access.

I agree on advertising on the CA forums. Anyone know of any other good sites/mailing lists to announce on?

Going to get around to working with the documentation, however, my current focus is on working with/localizing Eficas.

As for translation software, I guess you could say \" use what fits your style\". Currently I haven't seen any software that actually translates perfectly, but It can give someone that doesn't speak French, the basic gist of what is being said. Then that person can write the translation in their native language.

Document Format : Personally, if the documentation is going to be book/manual style, I think we should use OpenOffice and ODF. OOo has a fairly good export to PDF ability as well.
Using this method, a version can be distributed in a read-only, scalable style (PDF). And for those that are contributing they can make use of the Wiki and ODF. The wiki could also serve as a online quick reference.
Wiki and ODF could be labeled \"development/bleeding edge\".
PDF could be considered \"final/print ready\".
I expect the argument against PDF to be made at some point by someone. I acknowledge the horror of Acrobat Reader on Windows, but on Linux, Xpdf and even Acrobat Reader itself do not suck.

If anyone has some thoughts on this... please post!

-Jason
Moderators: catux
Time to create page: 0.208 seconds
Powered by Kunena Forum