Back in 2012 Tim confirmed that it would be 'fairly tough' to make a
multi-lingual EWB1 app.
Has anyone developed one in EWB2 or even tried?

I have an existing PHP app which supports about a dozen European
languages by user selection at runtime.
I am sure EWB2 will handle the functionality just fine, but can it
support user-selected or locale based languages without me having to
compile a dozen or so specific language versions?

I guess I would need to provide the necessary language files and load
all captions, etc, with their text from the active language file at
runtime like dggettext.
Or maybe a translation dataset?
Or what...?

I have a Multi-lingual EWB 1 app.

On show of every form the labels and captions are changed - or dynamically if they click FF or EN on the top right corner.

Walter

Great, Walter.

How have you managed the strings?
 * stored in each form as constants
 * stored in language files

Malcolm:

This was a small project so I stored them as constants in each form.

As I think about it now - when I do my next multilingual app - I would create a table to hold the text.  I would have a button that only shows when developing, on each form I would click that would then iterate through the captions and store them in a database (assuming English for me).  Then I would give the Users a Form to add a language.

This table would be globally loaded once and have all the necessary translation onshow for each form.

In the end my client improved upon my Google Translated attempt!

Just a thought....

Walter

Walter

All my existing multi-lingual apps/programs have been user-translated -
for free.  

For PHP I have used POEdit so I can simply send a text file with the
English and they return it with their translation included.
For Win32  and Android I have used TsiLang and again I just send a file
(actually binary) and the user translates it with the supplied editor
and returns the resulting file.

In both cases the two systems do all the hard work of coding/displaying
the correct language.  But with EWB it does not look quite so
convenient.

In one of my programs I have used a table to hold some translations so
that the program can run in one language while certain text can be in a
second language, neither being the default English.

Thanks for your feedback.  I will give it a whirl and see what I end up
with.

On 6/27/2015 12:30 PM, Malcolm wrote:
> In both cases the two systems do all the hard work of coding/displaying
> the correct language.  But with EWB it does not look quite so
> convenient.

Only in that it's not automatic with built-in capability at this time.

It would be fairly trivial to write a generic function that iterates
thru all the controls and changes their labels/captions/default text
based on control name.

It would need a way to look up translated string (either from table or
file resource).  Same function can collect the control names to generate
the source translation file (control name and current caption/label).

So it's very doable in a general sense.

Raul

>Only in that it's not automatic with built-in capability at this time.

>It would be fairly trivial to write a generic function that iterates
>thru all the controls and changes their labels/captions/default text
>based on control name.

>It would need a way to look up translated string (either from table or
>file resource).  Same function can collect the control names to generate
>the source translation file (control name and current caption/label).

>So it's very doable in a general sense.

>Raul

I have a multi lingual system using the idea explained by Raul.

http://www.aacrea.com.ar/indicadores2/

Every form calls a Translate procedure at show, sending itself as parameter, i.e. Translate(self)

The parameter is a TContainerControl type.

The procedure is recursive, if it finds a TContainerControl type, it calls itself.

As iterates by the controls (for n:=0 to cnt.ControlCount-1 do) you need to check what type is, because access to the caption property may be different between controls.

It goes a little tricky with grids column headers, but I managed to do it.

I lookup into a TStringList for the translation (it is a great feature for this that TStringList works also as a hash). The current language TStringList is initialized when user selects the language.

Regards,

Diego

Thanks, all.
That is very helpful.  It should give me something to do later in July.


Malcolm

Malcolm,

<< Has anyone developed one in EWB2 or even tried? >>

Since then EWB got a Translate method in the WebCore unit:

  function Translate(const ID: String): String;
  function Translate(const ID: String; const Values: array of String):
String;

along with this property:

http://www.elevatesoft.com/manual?action=viewprop&id=ewb2&comp=TFormatSettings&prop=Translations

Of course, I just realized that the list on that property didn't get updated
for EWB 2, but the list is also created in the WebCore unit.

Also, I've got on my list to add support for resource strings in EWB to the
compiler.  They will get stored as JSON in the HTML loader, just like
forms/control interfaces.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks for all that, Tim.

It seems I will have no excuse once Sam processes my order.