Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27232 > unrolled thread

Multi-language support on embedded plarforms

Back to article view | Back to comp.arch.embedded

Contents

  Multi-language support on embedded plarforms pozz <pozzugno@gmail.com> - 2017-09-05 09:30 +0200
    Re: Multi-language support on embedded plarforms David Brown <david.brown@hesbynett.no> - 2017-09-05 10:43 +0200
      Re: Multi-language support on embedded plarforms Robert Wessel <robertwessel2@yahoo.com> - 2017-09-05 09:56 -0500
        Re: Multi-language support on embedded plarforms Ian Collins <ian-news@hotmail.com> - 2017-09-06 07:50 +1200
          Re: Multi-language support on embedded plarforms Robert Wessel <robertwessel2@yahoo.com> - 2017-09-05 17:11 -0500
            Re: Multi-language support on embedded plarforms Keith Thompson <kst-u@mib.org> - 2017-09-05 15:17 -0700
              Re: Multi-language support on embedded plarforms Robert Wessel <robertwessel2@yahoo.com> - 2017-09-05 19:19 -0500
                Re: Multi-language support on embedded plarforms raltbos@xs4all.nl (Richard Bos) - 2017-09-09 12:37 +0000
                  Re: Multi-language support on embedded plarforms Robert Wessel <robertwessel2@yahoo.com> - 2017-09-09 16:16 -0500
                    Re: Multi-language support on embedded plarforms raltbos@xs4all.nl (Richard Bos) - 2017-09-15 17:17 +0000
            Re: Multi-language support on embedded plarforms Allan Herriman <allanherriman@hotmail.com> - 2017-09-06 11:27 +0000
    Re: Multi-language support on embedded plarforms Paul <paul@pcserviceselectronics.co.uk> - 2017-09-05 10:04 +0100
      Re: Multi-language support on embedded plarforms Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-09-06 10:55 +0100
    Re: Multi-language support on embedded plarforms Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-09-05 17:00 -0400
    Re: Multi-language support on embedded plarforms Keith Thompson <kst-u@mib.org> - 2017-09-07 10:55 -0700
      Re: Multi-language support on embedded plarforms scott@slp53.sl.home (Scott Lurndal) - 2017-09-07 18:41 +0000
      Re: Multi-language support on embedded plarforms pozz <pozzugno@gmail.com> - 2017-09-08 11:33 +0200
        Re: Multi-language support on embedded plarforms bartc <bc@freeuk.com> - 2017-09-08 11:32 +0100
          Re: Multi-language support on embedded plarforms David Brown <david.brown@hesbynett.no> - 2017-09-08 13:37 +0200
            Re: Multi-language support on embedded plarforms bartc <bc@freeuk.com> - 2017-09-08 14:48 +0100
              Re: Multi-language support on embedded plarforms David Brown <david.brown@hesbynett.no> - 2017-09-08 16:45 +0200
    Re: Multi-language support on embedded plarforms Richard Damon <Richard@Damon-Family.org> - 2017-09-08 10:43 -0400
      Re: Multi-language support on embedded plarforms Mel Wilson <mwilson@the-wire.com> - 2017-09-08 17:33 +0000

Page 2 of 2 — ← Prev page 1 [2]

#27284

On 08/09/17 15:48, bartc wrote:
> On 08/09/2017 12:37, David Brown wrote:
>> On 08/09/17 12:32, bartc wrote:
> 
>>> The method is basically this, assuming you have tables of messages for
>>> all languages in memory:
>>>
>>> * Take an English message M
>>> * Look it up in the English table, to get index N (with 100 messages,
>>>    a linear search will do)
>>> * If N is in range, return the string from table[N] for language L
>>> * If M wasn't found, just return M, the English version.
>>>
>>> So, probably a 10 or 20 line function.
>>
>> That can be okay for a starting point, but it has a /big/ problem - you
>> only get one entry for each original English language message.  When you
>> are translating messages, it is not uncommon to encounter different
>> messages with the same text in the original language but different texts
>> in the translations.  In gettext, this is done by including __FILE__ and
>> __LINE__ in the lookup.
> 
> The OP said there are 50-100 messages. Then any clashes (of the same
> English text with different meanings) can be handled manually.
> 
> But my scheme with references numbers can fix that. That can be extended
> to annotate messages give a general method of disambiguating messages
> with multiple meanings.

Indeed it will handle it.  But it means you have to have numbers in the
code, and match it up with numbers in the translation files.  Once you
start having that sort of thing, you lose the benefits of having a
simple direct text in the code.  So you might as well cut out that text
in the code and put it in the messages file.  And then you might as well
use an enumerated type - then instead of arbitrary numbers with no
connection to indexing and manual checking for collisions, you have a
header file with the enumerated type defined, symbols with useful names
(like "str_hello_world"), checking by the compiler for errors, automatic
completion from within your IDE, and fast and simple lookup in the
actual table.

> 
>>>
>>> This would require two copies of each English message, one in the
>>> source, and one in a searchable table. And that needs maintenance.
>>>
>>> You might be able to get around that by embedding a serial number in
>>> each English message:
>>>
>>>     puts(_("Please enter filename: !078"));
>>>
>>> Here the '!078" is the number and does not appear (or you can use {78}
>>> etc, any scheme will do).
>>
>> Maintenance of the string numbers here is a hassle.
> 
> No, the numbers can be anything, including any text, or can be
> annotations. 

Yes, it is a hassle - you have to be sure there are no conflicts, and
you have to match them up in your translation file.  That's easy for a
small program, but scales poorly and cannot be checked by the compiler.

> But in this scheme, every message must have an annotation,
> and that will can the appearance of the message within the source.
> 
> 
>>> Another reason to forget using anyone else's library.
>>
>> No, it is another reason to look at the licensing before using other
>> libraries.  People write libraries with the intention of letting other
>> people use them - you just need to make sure the licensing is suitable.
> 
> How does that library deal with the issues of extracting the messages in
> a format that can be submitted to a translator (who might be in a
> different country), and what format are they sent back in, or submitted
> to the program?

Do you mean gettext in particular, or some arbitrary library in general?
 The licensing issue was a general point.

gettext comes with tools to aid translating and maintaining the
translation files.  I'll let you look up the details - there is little
point in having me copy-and-paste stuff off the web.

> 
> What about when the program is revised, and messages are deleted, added
> or modified?
> 
> How does it deal with multiple instances of the same message that differ
> only in leading or trailing punctuation or capitalisation? Do multiple
> messages have to be provided?
> 
> What about the problem raised above of the same English words having a
> different meaning depending on context?

It is all handled by gettext.  Whether you like or dislike the way it is
handled, is up to you.  Again, look up the details if you want.

> 
> I looked at docs for gettext and it's a 275 pages in PDF format; 378
> pages in Word. How many messages did the OP want to deal with again?
> 

Since gettext is quite big, and has a license unsuitable for most
embedded software, it is unlikely to be the answer for the OP.  It is a
/heavyweight/ solution.  It might help inspire ideas for the OP, but it
is not a practical choice for him.  It is, however, and excellent choice
for many other projects and programs.  And there are several other
gettext-like libraries around, which might be a workable choice
depending on what the OP likes.


> (The scheme I outlined in my first post in the thread dealt with all
> this. And it totalled a few hundred lines of code. Actually I don't
> think I needed the translations at all; they could be loaded locally
> from a file, with an existing version of the application, so no
> intervention was needed.)
> 

The scheme you outlined is a possibility, and I'm sure the OP will
consider it.  It is not the way /I/ would do it (I mentioned that in my
first reply in the thread), but it could work.

[toc] | [prev] | [next] | [standalone]

#27283

On 9/5/17 3:30 AM, pozz wrote:
> [This message is posted to comp.arch.embedded and comp.lang.c]
> 
> Just for reference, an embedded platform based on a MCU with integrated 
> Flash, for example a Cortex-Mx device.
> Here I consider only western languages (left-to-right and european 
> chars, english, french, german, spanish and so on).
> 
> The main problem is the translation of strings, maybe 10-100 strings.
> 
> I know something about gettext package that can't be used in those 
> embeded platforms. However I like the approach of gettext.
> 
>    print_to_display(x, y, "Hello world!");
> 
> is simply changed in:
> 
>    #include <gettext.h>
>    ...
>    print_to_display(x, y, _("Hello world!"));
> 
> In this way, the code stays highly readble as before introducing the 
> multi-language support. If a member of a structure needs a string, it is 
> a char * as usual.
> 
> The solution I found in embedded platforms is to use an array of array 
> of strings: one index for the string and one index for the language.
> 
>    enum lang_t { ENGLISH, ITALIAN, LANG_N };
>    enum string_t { STR_HELLO_WORLD, STR_HOW_ARE_YOU };
> 
>    const char *strings[STRING_N][LANG_N] = {
>      {  // STR_HELLO_WORLD
>        { "Hello world!", "Ciao mondo" }
>      },
>      {  // STR_HOW_ARE_YOU
>        { "How are you?", "Come stai?" }
>      },
>    };
> 
>    static enum lang_t lang = ENGLISH;
> 
>    const char *_(int string_idx) {
>      return strings[string_idx][lang];
>    }
> 
>    void set_language(enum lang_t new_language) {
>      lang = new_language;
>    }
> 
> 
> I don't like too much this approach for two reasons.
> The first, the line:
> 
>    print_to_display(x, y, _(STR_HELLO_WORLD));
> 
> is much less readable than
> 
>    print_to_display(x, y, _("Hello world!"));
> 
> 
> The second, I need to change the type of some members/variables from 
> char * to int:
> 
>    struct mystruct {
>      int title;  // Instead of char *title
>      ...
>    };
> 
> 
> Another approach I'm thinking is to embed all the translations in the 
> string, using a separator character that can't be used in normal strings.
> 
>    print_to_display(x, y, _("Hello world!|Ciao Mondo!"));
> 
> The _() function will search the translated string based on the current 
> language. If he can't find, it could return the first translation 
> (english).
> 
> This approach has some disadvantages. It's difficult to exclude one 
> language from the build. If the languages are more than a couple, the 
> strings will be very long. The order of the translations (first english, 
> than italian, ...) is important and you have to remember it for every 
> string.
> 
> 
> What approach do you use?

If you really want to look by string, then your _ function just needs to 
search the translation table for that value, and then return the string 
desired translation instead of passing in the index. The lookup will 
take a bit of time, but not that long given your number of strings, and 
if you sort the strings by the base translation, you could binary search 
to find it.

[toc] | [prev] | [next] | [standalone]

#27286

On Fri, 08 Sep 2017 10:43:48 -0400, Richard Damon wrote:
> On 9/5/17 3:30 AM, pozz wrote:

>> The _() function will search the translated string based on the current
>> language. If he can't find, it could return the first translation
>> (english).
>> 
>> This approach has some disadvantages. It's difficult to exclude one
>> language from the build. If the languages are more than a couple, the
>> strings will be very long. The order of the translations (first
>> english, than italian, ...) is important and you have to remember it
>> for every string.
>> 
>> 
>> What approach do you use?
> 
> If you really want to look by string, then your _ function just needs to
> search the translation table for that value, and then return the string
> desired translation instead of passing in the index. The lookup will
> take a bit of time, but not that long given your number of strings, and
> if you sort the strings by the base translation, you could binary search
> to find it.

This may have been said already (who can tell, here), but the gettext 
convention 
_("Some string that has to be translated")

can make it easy for some preprocessors of your own to pick out these 
strings, manage a database of translations, and substitute  the 
translations into individual builds for each language.  The '_' can just 
be a syntactic marker -- doesn't need to be a callable function at all.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web