SYS$LANGUAGE
Syltrem
I can't find my OpenVMS Master Index.
Apparently it is not online either.
I'm looking for info on how to setup a new language in VMS (define
SYS$LANGUAGE FRENCH)
I have an application that would like the logical name changed to display
messages in the user's language, but when I change the setting, other things
bomb out.
Even the HELP has a problem with that (see below errors) but still provides
a clue to what needs to be done to setup a FRENCH language on my system
There is a logical name table that needs to be created and populated. But
then I can't find where this is explained in the doc so far. So if you have
the reference(s) from the Master Index or know where to find the Master
Index online...
Thanks for your help!
$ helpe/mess %LIB-W-ENGLUSED
%LIB-E-ACTIMAGE, error activating image
$1$DGA100:[SYS0.SYSCOMMON.][SYSLIB]MSGHL
P$FRENCH.EXE;
-RMS-E-FNF, file not found
%LIB-E-ACTIMAGE, error activating image
$1$DGA100:[SYS0.SYSCOMMON.][SYSLIB]MSGHL
P$FRENCH.EXE;
-RMS-E-FNF, file not found
Facility: LIB, Library Facility
Explanation: Translation of the logical SYS$LANGUAGE (or any logicals
depending on the specified language) failed, or the tables
supporting the selected language were not chosen by your
system manager. English is being used.
User Action: Examine SYS$LANGUAGE. Verify that the logical name table for
the language is built and that all logicals depending on
SYS$LANGUAGE (for example, logicals to supply spellings of
months and days of the week) are correct.
--
Syltrem
http://pages.infinit.net/syltrem (OpenVMS information and help, en français)
Ian Miller
SET LANGUAGE FRENCH
would be the way to change languages if the language was defined. This
command appears to be undocumented.
Syltrem
"Ian Miller" <i...@uk2.net> wrote in message
news:1158155896....@e63g2000cwd.googlegroups.com...
Thanks for this, I will certainly save the command, but:
$ set language french
%SET-W-LNGNOTFND, LNM$LANGUAGE_FRENCH not found; SYS$LANGUAGE not changed
%SET-W-LNGNOTFND, SYS$SYSROOT:[SYSHLP.FRENCH] not found; SYS$HELP not
changed
%SET-W-LNGNOTFND, SYS$SYSROOT:[SYSMSG.FRENCH] not found; SYS$MESSAGE not
changed
I still need to know how to setup a French language.
The errors above gave a new clue: the name of the logical name table !
But I don't know how to create it.
Regards,
Syltrem OVMS 7.3-1
Gorazd Kikelj
defined and then run a SYS$STARTUP:LIB$DT_STARTUP.COM
As for missing MSG and HLB files, you need to create/find them :-( .
Best, Gorazd
"Syltrem" <syltr...@videotron.ca> wrote in message
news:12gg41r...@corp.supernews.com...
Syltrem
"Gorazd Kikelj" <gorazd...@siol.net> wrote in message
news:CWUNg.4916$oj5.1...@news.siol.net...
> You need to define SYS$LANGUAGES to include all languages, that need to be
> defined and then run a SYS$STARTUP:LIB$DT_STARTUP.COM
>
> As for missing MSG and HLB files, you need to create/find them :-( .
>
> Best, Gorazd
>
I just found a 7.3 Master Index and the reference to
SYS$STARTUP:LIB$DT_STARTUP.COM
Thanks !
Peter Weaver
Besides the missing MSG and HLB files you might find that some commands do
not work once you setup a French Language (actually, the machines I setup
used CANADIAN as the language). IIRC MON CLUSTER, or maybe SHOW CLUSTER no
longer works (that plant was sold to another company and I no longer have
access to those machines to check which command it was). There were a few
others like HELP/MESSAGE that just bomb when you try them. This was on AXP
7.1. I always made sure that my account and the SYSTEM account were left in
English to avoid these problems. You might also find that you have
procedures that parse out the output from commands that will now show the
date in French and these procedures may fail now. I never heard of any of
the end-users having any problems with the language set to CANADIAN.
I asked HP (Compaq at that time) if I could get French HLB files and I was
told that the multi-language software was supposed to be a layered product,
but the product was killed before it was completed.
Peter Weaver
www.weaverconsulting.ca
CHARON-VAX CHARON-AXP Reflection PreciseMail
JF Mezei
> Hello !
Allo !
> I'm looking for info on how to setup a new language in VMS (define
> SYS$LANGUAGE FRENCH)
My guess is that you need to find a french language kit for VMS.
In the SPL for VAX, only ALLIN1 seems to be available in french. So I
suspect that the VMS operating system language options would come with
the VMS CD and not the layered product CD.
I know it used to be available in french (done at Valbonnes France with
some work done by the Digital Montréal office). Not sure if VMS is still
produced with the french language variant though.
Hoff Hoffman
> I can't find my OpenVMS Master Index.
AFAIK, it's no longer produced.
> Apparently it is not online either.
I tend to use www.google.com, with the keyword site: to restrict the search
to the URL for the documentation web server.
> I'm looking for info on how to setup a new language in VMS (define
> SYS$LANGUAGE FRENCH)
>
> I have an application that would like the logical name changed to display
> messages in the user's language, but when I change the setting, other things
> bomb out.
...
> $ helpe/mess %LIB-W-ENGLUSED
> %LIB-E-ACTIMAGE, error activating image
> $1$DGA100:[SYS0.SYSCOMMON.][SYSLIB]MSGHL
> P$FRENCH.EXE;
> -RMS-E-FNF, file not found
> %LIB-E-ACTIMAGE, error activating image
> $1$DGA100:[SYS0.SYSCOMMON.][SYSLIB]MSGHL
> P$FRENCH.EXE;
> -RMS-E-FNF, file not found
Unfortunately, that's been the behaviour for a while now within the default
environment. Circa V6.2 is when I first ran into that case. The pieces needed
to fully enable a particular language are not typically shipped in the base kit.
Without the MSGHLP$FRENCH image around, for instance, you can DEFINE [/table]
[/mode] MSGHLP$FRENCH to MSGHLP$ENGLISH to suppress the error. There may be
(are?) a few other troublespots, if you don't have the local language kit
loaded. (The regional/local folks will know if and what languages are available
in your particular area, I don't know that detail.)
The default mechanism used to start the language-specific tools is:
$ DEFINE SYS$LANGUAGES FRENCH
$ @SYS$MANAGER:LIB$DT_STARTUP
Syltrem
"Peter Weaver" <info...@weaverconsulting.ca> wrote in message
news:011901c6d75b$b95fb1d0$2802a8c0@CHARONVAX...
Hi
Thanks to all for the tips.
I might want to try CANADIAN at a later time to see if it's any better.
For the time being I had the programmer change his 300 programs (globally
with my search_replace.com) to use another logical name instead. He was
happy that was not much trouble.
I will not change SYS$LANGUAGE for the users, it may lead to different
problems that I don't want to get into.
Have a nice weekend everybody !
Syltrem
Neil Rieck
>
> "Peter Weaver" <info...@weaverconsulting.ca> wrote in message
> news:011901c6d75b$b95fb1d0$2802a8c0@CHARONVAX...
>> ----- Original Message -----
>> From: "Syltrem" <syltr...@videotron.ca>
>> To: <Info...@Mvb.Saic.Com>
>> Sent: Wednesday, September 13, 2006 11:30 AM
>> Subject: Re: SYS$LANGUAGE
>>
>
> Hi
>
> Thanks to all for the tips.
> I might want to try CANADIAN at a later time to see if it's any better.
>
> For the time being I had the programmer change his 300 programs (globally
> with my search_replace.com) to use another logical name instead. He was
> happy that was not much trouble.
> I will not change SYS$LANGUAGE for the users, it may lead to different
> problems that I don't want to get into.
>
> Have a nice weekend everybody !
>
> Syltrem
>
You've made the correct decision in moving your attentions to the
application.
I'm currently adding French support to some programs originally written in
English. Although there are tempting reasons to want to do this at the OS
level, it makes more sense to do this at the application level as soon as
you consider the need to support to support more than one language at a
time (so make it user selectable; save the choice in a cookie if a web app)
###
A Quebec labor law (still?) exists which basically states "as soon as you
turn up a software solution in English you are then obligated to add French
support within 52 weeks" (this is at the application level, not the OS). I'm
not sure if there is any obligation to add English to French applications
but any programmer crossing this threshold once will usually prepare for the
inevitable.
Here are some choices I've seen or heard about:
1) having multiple versions of the software with all the strings translated
into the desired language (you would not believe the number of companies
doing this; has to be a make-work project for the software industry; when
fixing bugs the multiple versions almost always slip out of sync)
2) hard code each string for two (using IF/THEN/ELSE) or more (using
SELECT/CASE) languages. (this seems like a good idea but will only work on
small progams; when programs grow hunting down bugs will become much more
difficult)
3) load the desired language strings into an array before the program runs.
You need to make sure the array subscripts in your source code are
descriptive. eg:
print #0, L$(k_choice);
input #0, choice$
Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/links/cool_openvms.html
Mark Daniel
WASD uses this approach.
http://wasd.vsm.com.au/ht_root/doc/htd/htd_1200.html
soyMAIL also.
Adding multi-language support is a significant undertaking for any
application. Not only the initial effort to build an application that
can dynamically handle multiple languages (and character sets) but the
on-going issues when modifying that application and needing to elicit
and then collate additions and modification to messages from a number of
independent sources (and being embarressingly monolingual myself). Adds
significantly to the developmental overhead.
Neil Rieck
"Mark Daniel" <mark....@vsm.com.au> wrote in message
news:12gnu3o...@corp.supernews.com...
> Neil Rieck wrote:
[...snip...]
>
> WASD uses this approach.
>
> http://wasd.vsm.com.au/ht_root/doc/htd/htd_1200.html
>
> soyMAIL also.
>
> Adding multi-language support is a significant undertaking for any
> application. Not only the initial effort to build an application that can
> dynamically handle multiple languages (and character sets) but the
> on-going issues when modifying that application and needing to elicit and
> then collate additions and modification to messages from a number of
> independent sources (and being embarressingly monolingual myself). Adds
> significantly to the developmental overhead.
>
You are 100% correct and it is just a fact of life for programmers working
this side of Y2K.
Paul Sture
"Neil Rieck" <n.r...@sympatico.ca> wrote:
Did this sort of thing many moons ago, although in the context of
layered software providing localised headings/prompts/error messages. In
that solution separate shared images were provided for each language, so
there was no concurrently mixing of languages.
> ###
>
> A Quebec labor law (still?) exists which basically states "as soon as you
> turn up a software solution in English you are then obligated to add French
> support within 52 weeks" (this is at the application level, not the OS). I'm
> not sure if there is any obligation to add English to French applications
> but any programmer crossing this threshold once will usually prepare for the
> inevitable.
>
> Here are some choices I've seen or heard about:
>
> 1) having multiple versions of the software with all the strings translated
> into the desired language (you would not believe the number of companies
> doing this; has to be a make-work project for the software industry; when
> fixing bugs the multiple versions almost always slip out of sync)
>
> 2) hard code each string for two (using IF/THEN/ELSE) or more (using
> SELECT/CASE) languages. (this seems like a good idea but will only work on
> small progams; when programs grow hunting down bugs will become much more
> difficult)
>
> 3) load the desired language strings into an array before the program runs.
> You need to make sure the array subscripts in your source code are
> descriptive. eg:
> print #0, L$(k_choice);
> input #0, choice$
3) would be my preferred choice, and meaningful names rule of course.
I've just had a look on my OS X system, which avoids 1) and 2) to see
how Apple do it.
For example, in the iTunes application, there are language specific
sub-directories, with localised messages in each.
A brief extract of the English and French Localizable.strings files
shows:
/* ===== Filenames ===== */
"128.001" = "Unknown Album";
"128.002" = "Unknown Artist";
"128.003" = "Unknown Genre";
"128.004" = "Unknown Podcast";
"128.005" = "Podcasts";
"128.006" = "Compilations";
"128.007" = "iTunes EQ Presets";
"128.008" = "iTunes Software License";
"128.009" = "Downloads";
/* ===== Dialog Strings ===== */
"130.001" = "Open Stream";
"130.002" = "Edit URL";
...
and in the French version:
/* ===== Filenames ===== */
"128.001" = "Album inconnu";
"128.002" = "Artiste inconnu";
"128.003" = "Genre inconnu";
"128.004" = "Podcast inconnu";
"128.005" = "Podcasts";
"128.006" = "Compilations";
"128.007" = "Préréglages de lšégaliseur iTunes";
"128.008" = "Licence dšutilisation dšiTunes";
"128.009" = "Téléchargements";
/* ===== Dialog Strings ===== */
"130.001" = "Ouvrir le flux";
"130.002" = "Modifier lšadresse URL";
...
I personally prefer mnemonics to numbers for messages, but either way,
you have to formally define the text strings in an application, which is
no bad thing.
--
Paul Sture
Dave Froble
#3 is headed in the right direction. But you want to get the 'data'
completely out of the program. By 'data', I'm referring to the strings
the program will be displaying, prompts, messages, etc. Once you
consider them data the concepts become simpler, since we're used to data
being separate from the application code.
There are many methods for setting up the data and getting it into the
application. Simplest to implement are text files. Sharable global
sections are another solution. Some more complex solutions will require
utility programs for setting up the 'data'.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Richard B. Gilbert
ISTR that VMS has built in facilities for this sort of thing. .MSG files
anyone? It should be fairly simple to set up multiple message files for
multiple languages. Find someone literate in French, German, Swahili,
etc, and have him create the text strings. Then you just have to open
the appropriate file for the language you are using to communicate with
the current user.
And you don't have to be able to read Lower Slobovian to support it
either. The user reports facility-severity-identifier and you look up
the matching text in the language of your choice.
JF Mezei
> Adding multi-language support is a significant undertaking for any
> application. Not only the initial effort to build an application that
> can dynamically handle multiple languages (and character sets) but the
> on-going issues when modifying that application and needing to elicit
ALLIN1 was built to handle multiple languages. Smart use of logical
names, as well as FMS libraries allowed easy switch of language setting.
$ show log oa$lib
"OA$LIB" = "OA$SITE_LIB_LLV" (LNM$SYSTEM_TABLE)
= "OA$SITE_LIB_SHARE"
= "OA$LIB_LLV"
= "OA$LIB_SHARE"
1 "OA$SITE_LIB_LLV" = "$DISK2:[ALLIN1.SITE.LIB_ENGLISH]" (LNM$SYSTEM_TABLE)
1 "OA$SITE_LIB_SHARE" = "$DISK2:[ALLIN1.SITE.LIB_SHARE]" (LNM$SYSTEM_TABLE)
1 "OA$LIB_LLV" = "$DISK2:[ALLIN1.LIB_ENGLISH]" (LNM$SYSTEM_TABLE)
= "OA$EXE_LLV"
2 "OA$EXE_LLV" = "$DISK2:[ALLIN1.OA$EXE_VAX_ENGLISH]" (LNM$SYSTEM_TABLE)
1 "OA$LIB_SHARE" = "$DISK2:[ALLIN1.LIB_SHARE]" (LNM$SYSTEM_TABLE)
= "OA$EXE_SHARE"
2 "OA$EXE_SHARE" = "$DISK2:[ALLIN1.OA$EXE_VAX_SHARE]" (LNM$SYSTEM_TABLE)
The LLV points to the local language variant (in this case english).
The SHARE points to the language independant files.
The SITE points to site specific directories (customised files, site
developped applications).
Installation scripts don't touch the SITE directories. And you can have
multiple languages residing on the same system with users accessing a
language or another simply via logical name definitions. (done by
ALLIN1/LANGUAGE=xxxx, or via teh language defined in the user's profile).
--------------------
Another impleentation is MOTIF's UIL files. These contain the widget
definitions, but can also contain all messages, strings etc. In
DECW$EXAMPLES, you can file a few demo apps that can be multilingual
simply by invoking a different compiled UIL file.
Mark Daniel
> Mark Daniel wrote:
>
>>Adding multi-language support is a significant undertaking for any
>>application. Not only the initial effort to build an application that
>>can dynamically handle multiple languages (and character sets) but the
>>on-going issues when modifying that application and needing to elicit
>
>
>
> ALLIN1 was built to handle multiple languages. Smart use of logical
> names, as well as FMS libraries allowed easy switch of language setting.
>
> $ show log oa$lib
> "OA$LIB" = "OA$SITE_LIB_LLV" (LNM$SYSTEM_TABLE)
> = "OA$SITE_LIB_SHARE"
> = "OA$LIB_LLV"
> = "OA$LIB_SHARE"
>
Yes. VMS' multivalued logical names offer remarkable possibilities in
environment tailoring. I have seen some clever applications of this
facility over the years. One that is proving to be less versatile and
more complex to implement (IMHO) on rehosting to *x.
WASD's multi-language support can use these for cascading
language-specific messages.
KLAATU$ show log httpd$msg
"HTTPD$MSG" = "HT_ROOT:[LOCAL]HTTPD$MSG_ES.CONF" (LNM$SYSTEM_TABLE)
= "HT_ROOT:[LOCAL]HTTPD$MSG_DE.CONF"
= "HT_ROOT:[LOCAL]HTTPD$MSG.CONF"
Earlier files can contain subsets with the last containing a base set.
The actual message presented on any one occasion can then be selected
according to the "Accept-language: .." request header, with a fallback
to the base language. Sounds a lot like what you describe below for
ALLINONE but wrapped up into a web-transaction.
soyMAIL takes the tack of allowing the user to specify an optioned
language and then loading a specific file containing those messages.
Again, the big issue (when you don't maintain all the language sets
in-house) is coordinating new and modified message sets. When relying
on volunteer input you don't want to make too many ad hoc changes and
have to pester these individuals too many times for trivial changes.
Neil Rieck
"Paul Sture" <paul.stu...@hispeed.ch> wrote in message
news:paul.sture.nospam-8...@mac.sture.homeip.net...
> In article <450befa8$0$24212$9a6e...@news.newshosting.com>,
> "Neil Rieck" <n.r...@sympatico.ca> wrote:
>
> I've just had a look on my OS X system, which avoids 1) and 2) to see
> how Apple do it.
>
It's been quite a while since I developed applications on a Mac (pre UNIX)
but they used to provide a special developer's tool called a "Resource
Editor". You would design an application referencing English (or whatever)
strings in your application's "Resource Fork". When you shipped your
application to users in another country, they would use the "Resource
Editor" to modify your application.
I also remember using resource fork data to filter legal keystrokes ("Y/N"
for English, "O/N" for French (Oui/Non))
###
Like you, I prefer to use meaningful mnemonics rather than meaningless
numbers.
In today's programming environment we provide initial alternative language
support files using http://babelfish.altavista.com then we ship the files to
someone more familiar with the other language for final tweaks.