When we do multilanguage Apps there is this poorely designed translation table in SC where we can assign certain texts to the strings and they are replaced on compilation.
Does anybody ever used a translatrion strings in the code ?
I mean like
$variable1 = {lang)something};
would this work ?
An interesting idea. It is a wish for a long time to be able to maintain the translation table outside of the development environment, so that you can delegate this process. But currently it is they only way…
Yes, it is
$variable={lang_yes} for example, shows ‘Yes’ for each languague you have included in your project.
I would be perfectly fine with using IMPORT/EXPORT of CSV file. The translation can be easily store in the database itself. If so, then we can easily do Import/Export directly into the database and would not need any extra tools or features in SCRIPTCASE at all.
This will also allow to switch language on the fly, allow to delegate traslations to AI and simplify development a lot. When done correctly creating a project which can work in 200+ languages would be a vreeze and would not require any external services, so it could run locally without Internet.
Not only this, but, there will be also possibility to share the translations among users so after building one big sharable database, instead of going through the translation process every time on a new project the system could simply look up the GLOBAL translation tables and translate 60-90% automatically. AI can manage language translations easily, btu without externalizing it (keepoin outside of SC) the work would be so tedious, that it would not worth the time.
If I have a project with 600 Apps, each Apps consists of several files, editing over 600 PHP files is as stupid idea as it gets. On top of that all the lookup tables must be translated as well (but this is much easier to do).
I just mentioned this in my recent Email to NETMAKE.
You already ask this question last year
The file is located at scriptcase/devel/conf/grp/project_name /lang and can easily be converted
Thanks for replying.
I never had time to look this up previously and have been under impression that this was kept in .php files.
OK, so if you would have a big project with 600+ Apps, what would be your workflow to translate it ?
The challenge here is to give it to some person who can do a translation but has zero knowledge of programin and only basic computer operation knowledge.
BTW. Here is what I do for the data translation. Here is an example of the YES/NO table which I use in dropdown selection lists.
In this table, if I want to add Spanish, I simply add 2 more records with the “SP” in the Lang column. Super simple and convenient.
If SC would use this type of approach and store Field Labels in the database like this the translation would be a breeze…
Theoretically this is doable but this should be implemented like this in the SC by default. At the present stage all the selection boxes have to be handled separately from the LANGUAGE page in SC which isn’t he best solution. If they at least allow LANGUAGE TRANSLATION page to Import/Export into CSV it woudl much simplify the translation process, because then one can simply open this in a spreadsheet, translate it and import it back.
No extra SC license woudl be needed.
Sending somebody all the .lang files means sending (in my case almost 600 files), which risks errors and extra problems.
It’s an option.
Why keep a table if you can do it with the SC language tool. For example put {lang_yes} in your code and put the translations in the tool.
For fields I use a global var [str_language] in the code or lookup sections:
select id, field1[str_language] from table…
and in sql appls you can use (in mysql/mariadb)
CASE
WHEN @vlanguage=“es” THEN field1
WHEN @vlanguage=“en_us” THEN field1EN
WHEN @vlanguage=“pt_pt” THEN field1PT
etcetera…
END as field1
Agree. I was talking about the drop-down selection lists. For the other fields your method works fine as well. I would rather stick to keep the functionality within php so if I need to switch databases it will still work.
For selection lists I use
select id, field1[str_language] from table
it works.
Fields are defined as
field1ES
field1EN
field1PT
etcetera
field2
field3ES
field3EN
field3PT
etcetera
