| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 1700.1 | Check with Frankfurt | AIMTEC::WICKS_A | Liverpool 4 Norwich 1 | Mon Nov 02 1992 16:37 | 10 | 
|  |     Allan,
    
    Firstly before you do anything with OALLV check with the people
    at the localisation/translation centre in Frankfurt as to why this
    change was made - they may be a very good reason why this change was
    made.
    
    Regards,
    
    Andrew.D.Wicks
 | 
| 1700.2 | Spreads like a virus | COPCLU::COPSPD::GLARGAARD | Allan Glargaard, DS @DMO | Tue Nov 03 1992 12:32 | 50 | 
|  |   As some of you have noticed, the problem spreads like a virus.
  All the mails we've sent from Denmark since the upgrade this weekend
  are of document type "MEDDELELSE" instead of "MAIL" on all other
  systems. This means that you can't read the header on mails received
  from us, the status will be "NOTED" instead of "READ" afterwards and
  you can't get rid of the damn' thing!
  We have fixed this now!
  -
  We've modified OALLV.BLI (Changed OA$GT_TYPE_MAIL from "MEDDELELSE" to
  "POST", BLISSed and linked) so no more mails should be sent out with
  this bug.
  The reason why the "MEDDELELSE" was not translated to "MAIL" is due
  to the /LANGUAGE=OA$_LANG_MAIL_TYPE qualifier on the TYPE field on DOCDB.
  The symbol translates to 
  "DOKUMENT,POST,LANGTIDSARKIV,DISTRIB LIST/DOCUMENT,MAIL,ARCHIVE,DISTRIB LIST"
  and therefore the "MEDDELELSE" goes directly into DOCDB without
  translation.
  -
  What do you do if you received any "MEDDELELSE":
  If you received any of these "MEDDELELSE", they can be fixed by
  executing the following for the user:
  <FOR CAB$ WITH .TYPE = "MEDDELELSE" DO -
  GET #X = .%KEY \\ WRITE CHANGE CAB$ %KEY = #X, TYPE = "POST"
  The user can then read the document as normal.
  -
  Why wasn't this found during QA in Frankfurt? 
  Well, one reason could be that there was no message router on the
  test system, not enough time to check everything, the test scripts
  were not good enough ...
  -
  There has always been translation bugs which the LEG's fixed
  themselves in local patches, but what do we do now the LEG's are
  gone? I myself am in customer services and am not supposed to have
  the time to make these patches! Will Frankfurt make the patches
  nessesary?
  Allan
 | 
| 1700.3 | Frankfurt will know what to do | AIMTEC::WICKS_A | Liverpool 4 Norwich 1 | Tue Nov 03 1992 16:45 | 12 | 
|  |     ALLAN,
    
    Just checking that you replaced OALLV in OALLV.OLB and
    SITEOALLV.OLB, OALIBR and SITEOALIBR (yes it does live in all 4 places)
    and of course you used CM (:==:)
    
    I am confident that if you bring this feature to the attention of
    the L10N centre in Frankfurt they will do the right thing.
    
    Regards,
    
    Andrew.D.Wicks
 | 
| 1700.4 | Use your local translation? | FORTY2::ASH | Grahame Ash @REO | Wed Nov 04 1992 10:02 | 17 | 
|  | >  What do you do if you received any "MEDDELELSE":
>
>  If you received any of these "MEDDELELSE", they can be fixed by
>  executing the following for the user:
>  <FOR CAB$ WITH .TYPE = "MEDDELELSE" DO -
>  GET #X = .%KEY \\ WRITE CHANGE CAB$ %KEY = #X, TYPE = "POST"
>
>  The user can then read the document as normal.
If I understand this correctly, the user has to user the local version of 
'MEDDELELSE' - so if an English or American user has one of these messages they 
should use:
  <FOR CAB$ WITH .TYPE = "MEDDELELSE" DO -
  GET #X = .%KEY \\ WRITE CHANGE CAB$ %KEY = #X, TYPE = "MAIL"
grahame
 | 
| 1700.5 | To clarify | SCOTTC::MARSHALL |  | Wed Nov 04 1992 12:02 | 11 | 
|  | .3 says:
>> OALLV in OALLV.OLB and SITEOALLV.OLB, OALIBR and SITEOALIBR
To clarify this: the US ENGLISH version of OALLV goes in [SITE]OALIBR.  The
local language version goes in [SITE]OALLV.
In theory, it shouldn't make any difference if you put a local language version
in OALIBR, but it's probably safer to keep things as they were intended.
Scott
 | 
| 1700.6 | How to fix NOTED and more | COPCLU::COPSPD::GLARGAARD | Allan Glargaard, DS @DMO | Wed Nov 04 1992 15:36 | 25 | 
|  | Re.: .3, Andrew
>    I am confident that if you bring this feature to the attention of
>    the L10N centre in Frankfurt they will do the right thing.
>    
  I'm currently investigating what the correct escalation procedure
  for me would be. Raising a CLD would probably end in cold water or
  am I very wrong in this assumption?
  A escalation template and an account to send it to would be greatly
  appreciated.
  One thing about the fix for the "NOTED" problem, you have to make
  sure all messages are transfered from PENDING.DAT to the user before
  you do the <FOR loop. 
  For each user, issue a 
  CABINET GET_PENDING "MAIL", OA$FOLDERS.INBOX[OA$ALLIN1_LANGUAGE]
  (Stolen from Tony's technical odyssey)
  Thanks for taking interest in this "local" matter :-)
  Best regards,
  Allan
 | 
| 1700.7 | Let us know when you find out | AIMTEC::WICKS_A | Liverpool 4 Norwich 1 | Wed Nov 04 1992 17:07 | 21 | 
|  |     Allan,
    
    The U.S CSC has no formal escalation path to Frankfurt. I cannot speak
    for the European CSCs maybe one of them can reply (P.S Basingstoke
    doesn't count in this case since they don't support I18N versions)
    
    A CLD would probably be over the top at this stage. I would open with
    an SPR to IOSG who at least have a semi-formal relationship with
    Frankfurt.
    
    The best and most productive informal method is to use ALL-IN-1 and
    send mail to the L10N centre.
    
    My interest in this topic stems from my involvement a few years ago
    in having to fix part of the Mail code to handle the Finnish word for
    Yes which is KYLLA (sorry can't do the funny little o on top).
    
    Regards,
    
    Andrew.D.Wicks
                                                                      
 | 
| 1700.9 | No official support channel open | PETRUS::MIETHE | Frank Miethe, LC Frankfurt, ISE | Thu Nov 05 1992 13:12 | 24 | 
|  | RE: .0
	Allan,
	after looking to the danish terminology I found the term 'MEDDELELSE'
    	is wrong. As you said it should be 'POST' as it was in V2.4.
	But in general the OA$GT_TYPE_MAIL has to be exact the same string as
	the corresponding one of OA$_LANG_MAIL_TYPE in OA.A1$MSG. This is the 
	only way to translate it internally to 'MAIL' (so RE: .4 Grahame is
	right). When a user get's this mail in an other language, it will be 
	translated back to the LV corresponding string.
RE: .7
	Andrew,
	there is until now no official way that the LC Frankfurt gets involved
	in escalation!
	But I think thats no way we can go, so I asked Product Management to
	find a way to get money for this. When my management says do the LV
	line support I will do (and I would like it to do)...
Regards,
	Frank
    
 |