Multi-language support on embedded plarforms

On Sat, 09 Sep 2017 12:37:46 GMT, raltbos@xs4all.nl (Richard Bos)
wrote:

>Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>> On Tue, 05 Sep 2017 15:17:56 -0700, Keith Thompson <kst-u@mib.org>
>> 
>> >Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> >> Well yes, (and ours are text based), but I've yet to see a SCM that
>> >> can tell you that someone updated the English version of message#14,
>> >> but hasn't validated or updated the Italian one yet.  You can
>> >> certainly get a diff and manually see where changes have been made,
>> >> but that still leaves you with a manual comparison to the
>> >> translations, and no way of tracking that the validations have been
>> >> done.
>> >
>> >The "git blame" command tells you, for each line in a file, when that
>> >line was most recently modified.  Other SCMs have similar tools.
>> >I imagine you could build some tools on top of that that could
>> >warn you, for example, that the English version of message #14 was
>> >updated yesterday but the Italian version hasn't been changed in
>> >the last year.
>> 
>> A problem is when a change needs to be made to only some translations
>> of a message.  Let's say the English one was awkwardly worded, and
>> thus modified, but (some of) the other translations don't need to be
>> changed (although they should probably be reviewed).
>
>I'd like to point out that none of that is a technical problem. It's a
>management (and sometimes political) problem, and therefore needs a
>solution at a management level, not primarily a technical one. There may
>be technical _aids_ to the managerial solution, but not a technical
>solution /per se/.


Sure, but you can say the same about source code and configuration
management too.

Robert Wessel <robertwessel2@yahoo.com> wrote:

> On Sat, 09 Sep 2017 12:37:46 GMT, raltbos@xs4all.nl (Richard Bos)
> >Robert Wessel <robertwessel2@yahoo.com> wrote:
> >
> >> A problem is when a change needs to be made to only some translations
> >> of a message.  Let's say the English one was awkwardly worded, and
> >> thus modified, but (some of) the other translations don't need to be
> >> changed (although they should probably be reviewed).
> >
> >I'd like to point out that none of that is a technical problem. It's a
> >management (and sometimes political) problem, and therefore needs a
> >solution at a management level, not primarily a technical one. There may
> >be technical _aids_ to the managerial solution, but not a technical
> >solution /per se/.
> 
> Sure, but you can say the same about source code and configuration
> management too.

Yes, and I do. If you can't do a desk check, but require a colour-coding
IDE to read your code, you're not a programmer, you're a hack. Liking
syntax colouring is fine, it's needing it which is the problem: the IDE
should aid your code comprehension, not create it.

Similarly, if you can't work with two people on one problem without
needing to go through Github, you don't have enough social skills to be
a team player. Two thousand is another matter, but there, too, the basic
problem is organising the teams, _not_ setting up the Git repository.


Richard