[Gambas-user] Some questions about project Translation
sebikul at ...626...
Mon Sep 24 21:27:34 CEST 2012
On Sun, Sep 23, 2012 at 2:44 PM, RICHARD WALKER
<richard.j.walker at ...247...> wrote:
> On 23/09/2012, Sebastian Kulesz <sebikul at ...626...> wrote:
>> On Sun, Sep 23, 2012 at 1:08 PM, RICHARD WALKER
>> <richard.j.walker at ...247...> wrote:
>>> So I was wondering, does it make sense to re-code a project so that
>>> strings, or string constants are used for repeated fragments of text?
>>> Might such an approach actually make it harder to translate
>>> "sentences" made of these fragments into some languages?
>> Normally, you should avoid this. If you have string like:
>> Are you sure you want to $action this?
>> $action being move, delete, copy, etc. You should keep the repeated
>> strings. Different languages have different syntactic order, having a
>> generic string can be really hard to translate if there is a specific
>> language that uses a different order for different possible $actions.
> Good point, Sebastian. I had suspected this to be the case. If I have
> coded with string constants or variables for ease of maintenance, how
> would I get the plain text versions of the built strings into the
> translation file? Is it just a matter of enclosing the concatenation
> of String/Const and text in parentheses?
You should never concatenate translated strings unless necessary.
Always use Subst()
>>> And finally, in examining my code for translatable strings I realised
>>> that I had made extensive and vital use of text written by various
>>> shell commands and captured for analysis/action in various Process
>>> Read and Error handlers. That started me wondering how to handle this
>>> situation in another language where the text written by these
>>> processes would likely be very different from what I was expecting.
>>> Any ideas?
>> The best solution would be to force the use of the English language by
>> setting the environmental variable LANGUAGE.
>> You can do that like this:
>> Shell "LANGUAGE=en firefox" to sOutput
>> If you want this to persist, you can create a virtual terminal inside
>> a process instance and execute (i did not test this, but it should
>> work) before any other command:
>> Print #hProcess, "export LANGUAGE=en"
>> Hope this helps you!
> That looks like a very workable solution. The various processes'
> console output will only ever be seen by the Gambas project running
> them, so it makes sense to force a particular expected language rather
> than leave it to chance and LOCALE. I will try that later this
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
More information about the User