Language pack or built language on the main installation?

[Eulogy]

I will work on the language translation of Sentora during the next few weeks.

What do you prefer? Make the language built in on the main sentora installation

Or..

Make languages pack where the people can adds?


or both... built in for the most populars languages and make language pack for the others onces.  

E.S. 

[TGates]

We are eventually planning on making external language packs. This way also Modules can be translated with their own language packs too.

Something like:
/panel/languages/en-US.php

/panel/modules/[modulename]/languages/en-US.php

We already have a basic framework we have decided on but it will be for a later release.

I will have a chat with Me.B and refresh my memory on the plans.


My proposed version would allow us to use something like this: http://translate.supersimplecms.tk/ for use with the core translations depending on how we decide to work the variables..

[Eulogy]

ATM all the variables are on the table x_translations of the sentora_core.
Just to do a sql request with a altern table with a update for each id_pk.
It's look fine and easy to use, but probably not optium with many columns.

Do you think to use a other method for the futur release? I'm not sure about the php files, maybe a xml may be more useful and easier to dev on for the community.

[TGates]

I have worked with many projects, and using a different file for each language is very common and easier (and faster) than using a database driven translation system. When we started Zpanel, it was file based. But as things progressed we tried, and switched to db based as our lead developer at the time figured it would be easier to maintain. Which has since proven different
We even had a translation site which is now offline that allowed members to edit and add translations that, using a module, could update and import new languages into the database with ease. One of the main drawbacks of using the db for translations is that custom modules, like sentastico,  error pages editor, etc. Would also need to be incorporated making the language database huge depending on how many languages you wanted to support. And, if you didn't use sentastico, the translations would still be there. Using language files for the core and separate language files for modules proves to be much easier to maintain and create. And if the selected module language doesn't exist it can fallback to English (Sentora default). The hard part is sorting out how to 'easily' convert the current db style to read from files instead of the db without rewriting all of the coding...

[TGates]

Ok, after I said all that lol.

Xml would be too 'complicated' as I worked with that also.

Using an array or defining the variables is much easier.

Basically in the core you have, for example,  _logout
Now, in your language file it would be  something like: _logout = "Logout";
Now, if something is not translated,  you would see either _logout or the English (default) equivalent (depending on how we code that).
If you want, I can show you the source and examples for translations of the project I mentioned above to help give you a better idea through PM.

[tkramer]

Very good! You can count me in the translation to Brazilian Portuguese!

[Eulogy]

Oki, so I will work on the x_translation table for now, and when the new architecture will be ready for the next Sentora Version, just tell us the way the standard will set and we will transfert our translation on the new standard.

So we will be able to have more than just english at the start of the new version.

[Eulogy]

If some people want to help for the translation of your language, please just to push the sql dump of your x_translate table as attached file on this post. I will work on a sort language pack script for update the DB with your translation DB.