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


Groups > comp.arch.embedded > #27278

Re: Multi-language support on embedded plarforms

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded, comp.lang.c
Subject Re: Multi-language support on embedded plarforms
Date 2017-09-08 13:37 +0200
Organization A noiseless patient Spider
Message-ID <ootvem$gpm$1@dont-email.me> (permalink)
References <ooljr9$2kp$1@dont-email.me> <871snil7g3.fsf@kst-u.example.com> <ooto66$6ff$1@dont-email.me> <IkusB.792292$Bj2.352282@fx24.am4>

Cross-posted to 2 groups.

Show all headers | View raw


On 08/09/17 12:32, bartc wrote:
> On 08/09/2017 10:33, pozz wrote:
>> Il 07/09/2017 19:55, Keith Thompson ha scritto:
> 
>>> In a very quick look at the gettext sources, I see that the
>>> gettext-runtime/src subdirectory contains about 1300 lines of C code.
>>> If that's all that needs to run on the target system, you might even be
>>> able to use it without modification.
>>
>> This is a good suggestion. I'm not an expert of gettext, however I
>> remember it loads/search for right strings (based on current language)
>> at runtime, looking at the content of a binary file (mo extension).
>>
>> In my embedded platform I don't have a real filesystem so I can't
>> access "files" at runtime.
>>
>> Maybe I could add the mo files in the output binary file (the image of
>> the Flash memory of the MCU) at exact locations and change gettext
>> code to look at those fixed addresses instead of accessing files.
>>
>> Anyway thanks for the suggestions.
> 
> gettext looks like a very heavy-duty approach. (A lot of these third
> party solutions are. My experience was that a third party library that
> took care of 5% of the functionality of my application, would be several
> times bigger than my entire app.)

gettext /is/ a heavy-duty approach.  It is designed to separate the
program code and that translation texts, so that they can be written by
different people, compiled separately, distributed separately, and (if
desired) updated separately - because the binary and the translation
files are all separate files.  It is a very useful approach for many
kinds of program - but too big and complex for what the OP wants, I believe.

> 
> 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.

> 
> 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.

> 
> Now you just have to search the table for language L for a message with
> the same number. (You don't need to convert to an integer, just compare
> the last few characters.)
> 
> Of course, you need to return a string without the !078 etc in it. For
> that purpose, it might be better to put this number at the start. Then
> you return a string pointing to the just past the number.
> 
> (See example below using such a scheme. This might give some ideas.)
> 
> You can use the number as an actual index, but the maintenance becomes
> harder.
> 
> There is still the problem of producing a list of English messages for
> translators to work from. But the format and ordering of that is not
> critical.
> 
>>> (Any licensing issues are left as an exercise.)
>>
>> And this is another good point to study.
> 
> 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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web