[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

445.0. "What about internaitionalization of Text Messages" by FMCSSE::HEINTZE () Tue Oct 30 1990 21:09

VMS provides the message facility which allows a means for you to ship a 
product whereby the customer can install the product and translate the MSG file
into his native language(s).  The customer can then
 have different users receive the same message
translated into their native langauge(s) without ever having to recompile or
relink the product!   As you probably know, this is done by compiling and
linking the MSG file as a shared image.  If someone is provided the MSG file,
he/she can create their own MSG file in their native langauge, compile & link
it as a shareable image and - with a logical name definition - receive 
text messages in their native langauge.

I don't know much about MCC but I need to learn.  Does MCC provide a portable
messages
facility?  Can someone provide me page number in the documenation?

I just learned about mtext.  Apparently this is portable version of the 
VMS message facility that is compatible with the VMS message facility.  They
are entering alpha test very soon.  See the notes conference on DECWET::MTEXT.

Since our project needs to run on most of the DEC blessed platforms we will
be using MCC.  But we also want internationalizable messages so I need to 
know if mtext is redundant with the capabilities of MCC.

                                            Sieg
T.RTitleUserPersonal
Name
DateLines
445.1half way there.GOSTE::CALLANDERTue Nov 20 1990 15:4120
    We are working on the internationalization issues all of the time.
    We started this effort with the text. MCC attempts (and some time
    in the future wants to be complete in this area) to store all text
    external to the code. This is done using message files and the
    dictionary files. If the text of the Management Specifications (input
    files for the dictionary) and the message files are translated to
    another language that is half the battle.
    
    The other half that we are still working on are things like the
    different ways in which numeric values, dates, and times are displayed
    and input; as well as the difference in text characters (accents
    and the such) and their input (right to left versus left to right...).
    
    There is still a long way to go to be a completely internationalizable
    product without requiring some edit work and relink, but the message
    files for all of the tools and MCC proper, along with the Management
    Specifications is a good start.
    
    jill
    
445.2I18N, plans and strategyKHUMBU::SEVIGNYArctophile by AccidentFri May 03 1991 20:1120
    
    
    Our group (DECtp) is using MCC as the director, and the first release
    of our product will support the Kanji and Katakana character sets.
    
    Aside from translating, (called localization) we also would like to see
    international support for data representation of locale-specific
    information (such as date/time, numeric separators, etc...).  But most
    important, we would like to see support for MOCS or Unicode character
    sets (and the resulting issues such as collation).  
    
    We have no "requirement" that directives and entity class names be
    represented in Kanji, but in order to be a competitive product, that
    would be a big plus.
    
    Any comments on the state of internationalization and MCC?
    
    Marc                            
    
    order to handle Kanji.
445.3any more progress in this area?SKIGOD::PFROMERPfroamin' at the mouth...Fri Oct 11 1991 13:2013

Has there been any more progress in this area?  

The product I'm working on will provide an MCC compliant generic interface
to various media loader robots.  We plan to allow 3rd parties to develop
"media robot drivers" (code which manifests a particular robot) that will
plug into a "media robot server" MOM provided by DEC.  A problem I have is
how to allow the 3rd party developer to specify additional robot specific
error messages WITHOUT having to coordinate his/her product release with
our product release.

Any ideas?
445.4Internationalization will have to waitTOOK::CALLANDERMCC = My Constant CompanionWed Oct 23 1991 21:288
Right now we are very busy trying to get V1.2 out to field test. 
No major investigations are going on into any of these areas at
this time. To do many of the things you are requesting (like
language specific value formats) will require coding changes.
One of the changes we would like to make is to provide a mechanism
where you could enroll routines for datatype conversions directly into
the kernel system ,so you could modify the interpretation of data on
input and output without having to modify the base system.