| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1788.1 | Have you reported them formallY? | AIMTEC::WICKS_A | Liverpool 4 Norwich 1 | Mon Nov 16 1992 16:48 | 20 |
| Jan,
the first question that springs to mind is are you really sure
that they are translation bugs? the second is have you contacted
Frankfurt?
The CM one i've seen on U.S English systems and Simon produced an
excellent document that contained this and the other 869 CM error
messages (it's in STARS)
The WP one doesn't appear on ny multi-ling system but I only have
French as a second-lang.
The last 3 I can't reproduce since I only have systems with U.S English
as a primary English and they don't appear when you have one of them
there Euro languages installed secondary.
Regards,
Andrew.D.Wicks
|
| 1788.2 | Working... | UTRTSC::SCHOLLAERT | AJAX beats Feyenoord again and again | Mon Nov 16 1992 20:35 | 52 |
|
Andrew,
> the first question that springs to mind is are you really sure
> that they are translation bugs?
Yes, at least for the first 4.
> the second is have you contacted
> Frankfurt?
Not yet. I expect more calls from this customer...
> 1) Fresh Installation reports "error CM022, refer to documentation"
Element A1LINK.COM has "DUTCHN" as .language in CM$SDC$DUTCH.DAT.
Should be "DUTCH".
After the merge, Simon compares the number of records with .language eq
SHARE or DUTCH in CM$SDC.DAT with the total number
of records in CM$SDC$DUTCH.DAT. result in error CM022.
I afraid Simons list only applies for "normal" failures.
> 2) Author field on form WP is always empty
/GET=AUTHOR,OA$CURDOC_AUTHOR missing on form WP
> 3) Modification of datasets by typing the entry form name does not work.
> Prompt is in English. Choices in Dutch. Half of the Dutch
> choices fail.
Screen text not translated. Mismatches between
contents of OA$_ENTRYMENU_TABLE and OA$_MO_ENT_mumble .
> 4) ALL-IN-1 accounts IVP, A1$SCRIPT contain "NO MAIL" for
> maildes. Not valid in Dutch. Modification to "GEEN POST"
> does not work. Next time you perform an Edit, "NO MAIL"
Looks like a problem in /LANG=xx$_LANG_MAIL_DESTINATION
on MAIDES .
Fails for SM MUA E as well as US SWC .
I did a quick $ search *.a1$msg lang_mail . Not
all symbols are translated.
> 5) ALL-IN-1 accounts IVP, A1$SCRIPT contain
> "Start hour: 08:00A" and "End hour: 05:00P". "A" and "P" are
> not valid on non-english versions like Dutch.
Have to check the intallation procedure.
Regards,
Jan
|
| 1788.3 | MAIDES /RECOG and /LANGUAGE conflicting ? | UTRTSC::SCHOLLAERT | AJAX beats Feyenoord again and again | Tue Nov 17 1992 06:32 | 52 |
| re.2
>> 4) ALL-IN-1 accounts IVP, A1$SCRIPT contain "NO MAIL" for
>> maildes. Not valid in Dutch. Modification to "GEEN POST"
>> does not work. Next time you perform an Edit, "NO MAIL"
>
> Looks like a problem in /LANG=xx$_LANG_MAIL_DESTINATION
> on MAIDES .
> Fails for SM MUA E as well as US SWC .
> I did a quick $ search *.a1$msg lang_mail . Not
> all symbols are translated.
Hmm, I have been jumping to conclusions on this one.
Difference between 2.4 and 3.0 is that om SM forms, which
are not translated, the fields are displayed with the English
values. So that must be the reason that SM$_LANG_MAIL_DESTINATION
contains the English values twice and SA$_LANG_MAIL_DESTINATION
(used in translated Administrator Forms) is translated.
The problem is that OA$MAIDES, which is used for recognition
and validation on field MAIDES always checks for the Dutch translation
of MAIDES.
How is this supposed to work ?
Regards,
Jan
SM$PROFILE :
;;MAIDES;;
/HARD=OA$_SM_HRD_MAIL_DEST/RECOG="OA$MAIDES"
/VALID=<XOP ~~VALID_MAIDES~~
/LANGUAGE=SM$_LANG_MAIL_DESTINATION
result of /recog :
1 ALLIN1
2 ALL-IN-1
3 GEEN POST
4 PRINTER
5 AFDRUK
6 HARD-COPY
7 VMSMAIL
8 VAXMAIL
<get SM$_LANG_MAIL_DESTINATION
NO MAIL,MAIL-LIST,PRINTER,HARD-COPY,PAPER MAIL/NO MAIL,MAIL-LIST,PRINTER,HARD-CO
|
| 1788.8 | This is what I received from the I18N Product Manager | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Fri Nov 20 1992 11:27 | 60 |
| International Systems Engineering (ISE)
ALL-IN-1 Problem Reporting
ESCALATION FLOW AND PROBLEM REPORTING
The ISE/Localisation Centres are connected through ECSO to the
European Support Centres. This means that the official way of
escalating problems should go through the Customer Service
Centres. When using ECSO the Site "FLC" (Frankfurt Localization
Centre) should at least be informed and if necessary support
should be requested.
The FLC will track for the upcoming problems and deliver either
solutions or give statements. The FLC expects that the
qualification of a problem, that was done by a Customer Support
Centre, identifies the problem as a localisation or
internationalisation problem. Software problems regarding the
Base Component reported to Frankfurt will be passed over to IOSG
and vice versa, L10N problems reported to IOSG will be passed
over to Frankfurt. In both cases the first site that was involved
will give a statement to the issuer of the problem, that the
problem has been passed over.
PATCH KITS FOR LLV's
The FLC works closely to IOSG Support and will either deliver a
patch for an LLV or ensure that a patch delivered by IOSG Support
contains the fix. Fixes will be integrated where possible in the
next version of ALL-IN-1.
COMMUNICATION
Usually the Customer Support Centres will be informed directly
from the FLC about the availibilty of a patch or a fix.
The FLC is planning to install a notes conference. This
conference will not only give the same level of information to
other persons inside Digital who don't have access to "TIMA"
and/or "STARS", but it will also be used to discuss localisation
(L10N) and internationalisation (I18N) issues. Announcement will
be soon.
IF NON OF THE ABOVE WORK...
Peter Hanspach
ISE ALL-IN-1 Product Management
Mail Address:
PAULUS::HANSPACH
Peter Hanspach @FRO
Phone:
DTN: 861-3576
EXT: 49 6103 383576
|
| 1788.10 | One question left | UTRTSC::SCHOLLAERT | AJAX beats Feyenoord again and again | Mon Nov 23 1992 14:13 | 20 |
| Thanks for all the replies.
Could someone have a look at .3
I am still confused how processing of MAIDES on SM$PROFILE
is supposed to work.
;;MAIDES;;
/HARD=OA$_SM_HRD_MAIL_DEST/RECOG="OA$MAIDES"
/VALID=<XOP ~~VALID_MAIDES~~
/LANGUAGE=SM$_LANG_MAIL_DESTINATION
OA$MAIDES is "translated". SM$_LANG_MAIL_DESTINATION is not.
So one of them should be modified. Which one ?
Thanks,
Jan
|
| 1788.11 | Change the form (IMHO) | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Mon Nov 23 1992 17:06 | 20 |
| A quick search for "PAPER" revealed several other symbols:
OA.A1$MSG:
LANG_MAIL_DESTINATION <NO MAIL,MAIL-LIST,PRINTER,HARD-COPY,PAPER MAIL>
SA.A1$MSG
LANG_MAIL_DESTINATION <NO MAIL,MAIL-LIST,PRINTER,HARD-COPY,PAPERMAIL...
SM.A1$MSG
LANG_MAIL_DESTINATION <NO MAIL,MAIL-LIST,PRINTER,HARD-COPY,PAPERMAIL...
Personally I would say that OALLV is right, and that you should change
the form to match. Problem is that there doesn't seem to be a symbol to
use. Hence this is a base bug. I think you'll need to hardcode it for
now.
Of course you'd need to test this, but it's (relatively) easy to change
it in the form!
Graham
|
| 1788.12 | Translating LANG_MAIL_DESTINATION solves problem | UTRTSC::SCHOLLAERT | AJAX beats Feyenoord again and again | Mon Nov 23 1992 21:32 | 34 |
| Graham,
RE.-1
Checked the dutch messages files and forms for usage
of LANG_MAIL_DESTINATION.
> OA.A1$MSG:
> LANG_MAIL_DESTINATION <NO MAIL,MAIL-LIST,PRINTER,HARD-COPY,PAPER MAIL>
Not translated. Used in SWC. Fails.
> SA.A1$MSG
> LANG_MAIL_DESTINATION <GEEN POST,POSTLIJST,PRINTER,HARD-COPY,AFDRUK/NO MAIL,MAIL-LIST,PRINTER,HARD-COPY,PAPER MAIL>
Translated but not used in SA$PROFILE. SA$PROFILE contains hardcoded
/LANG .... Should have worked when used.
> SM.A1$MSG
> LANG_MAIL_DESTINATION <NO MAIL,MAIL-LIST,PRINTER,HARD-COPY,PAPERMAIL...
Not translated. Used in SM$PROFILE. Fails.
I added the translated version of LANG_MAIL_DESTINATION in SITE$SM.A1$MSG
and SITE$SA.A1$MSG. All seems to work now.
By the way, I had a hard time to
find out that you have to precompile a form library when your
change the contents of a symbol, used in the named data (SWC in
OAFORM in the case).
Thanks for your help,
Jan
|
| 1788.13 | Where has LLV support gone now??? | COPCLU::COPLE4::GLARGAARD | Allan Glargaard, DS @DMO | Tue Nov 23 1993 10:36 | 18 |
| Rumour has it that the Frankfurt Localisation Centre does no longer
exist. I haven't seen any official statement about this, maybe one
of you could forward me the official story.
I have a LLV problem that I need to report, how should I do that?
best regards,
Allan who will certainly miss the excellent work/support from
Germany!!
PS The problem I need to report is about the oa$at_data_sort_table
in OALLV.BLI. It can be used together with BIND/SORT_KEY to sort an
index on a given field, but the table has not been adapted to local
sorting rules. I have a modified table for Denmark if anyone wants
it.
PPS I'll try to ask Peter Hanspach about the LLV support also ...
any relevant answer will be posted here also
|
| 1788.15 | use ECSO for problems | FROCKY::HOFMANN | Stefan Hofmann, IST FiWi @FRS | Tue Nov 23 1993 14:07 | 34 |
| Allan,
yes, it's true, the Frankfurt LC has been closed. Work (on ALL-IN-1) was
passed over to our colleagues in ISE/Tel Aviv. They will take care about
future ALL-IN-1 localization - with translation support from ISE/Valbonne.
You won't be very lucky with asking Peter Hanspach. Like me he already
started a "new career" somewhere with Digital.
If you or somebody else wants to report problems, you should continue
to use the ECSO channels. There is still one ALL-IN-1 engineer left in
the former LC who will handle these issues. By the time he finds a new
job I hope that Israel has committed to continue V3 support.
As far as your sorting problem is concerned, I can remember that we
discussed this very intensively during the localization process. Elin
Christensen brought it up.
If my memory serves me well, we could not implement language or country
specific sorting tables in the standard product, because:
1) we had to introduce new NCS collating sequences and conversion
functions and we were sure that not all customers would like the idea
that a layered product changes the NCS mechanism of there VAX
2) we expected problems in multilingual installations because of the
different DOCDB.FDL needed.
Maybe you should ask Elin for the outcome of our discussion
Sorry, don't have more details, as my old pointers are slowly
fading away,
regards,
Stefan
|
| 1788.17 | ECSO works, support from Frankfurt is great! | COPCLU::COPLE4::GLARGAARD | Allan Glargaard, DS @DMO | Wed Nov 24 1993 13:31 | 13 |
| Re. 1788.15, Stefan,
I reported my problem through ECSO like in the old days and got
excellent support from Frankfurt like nothing had happened! That's
what I call keeping up the good spirit!
One thing though: the sorting I'm talking about is not the default
sorting of DOCDB.DAT, its the sorting done with BIND/SORT_KEY when a
user (or application) asks for a sort by this table explicitly.
Best regards,
Allan
|
| 1788.23 | It's always in the STARS! | AIMTEC::WICKS_A | Atlanta's Most (In)famous Welshman | Thu Jan 13 1994 16:35 | 12 |
| Charly,
there's a STARS article entitled
*INTERNAL* Responsible Parties for LLV Translation of ALL-IN-1
which givesyou the names you need.
I suspect though that the parties involved may already be on there
way to sunny Reading.
Regards,
Andrew.D.wicks
|
| 1788.25 | Support from Tel-Aviv on its way | TAVENG::WEISSBREM | Ittamar - Israel Engieering | Thu Jan 27 1994 10:41 | 14 |
| Hi,
Yes, I18N and L10N job of ALL-IN-1 has "relocated" to Tel-Aviv (i.e.
ISE Israel) with translation support of Valbonne. Building of a team
takes time...
So although funding for support is still some place on the way, we are
getting structured and hope to be responsive soon. Proper announcement
will be made.
Regards,
Ittamar
|