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

Groups > comp.arch.embedded > #27284

Re: Multi-language support on embedded plarforms

Cross-posted to 2 groups.

Show all headers | View raw

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.

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