Hi Folks,
currently, I'm involved with a Unicode migration project (under ECC 6.0) and we have some minor issues with ABAP code where Chinese literals have been hardcoded for example as default-values for a selection-screen parameter or are used in a comparison against values provided via an Excel-upload (that's the two cases uncovered so far, but I guess there'll be more, possibly for other languages as well).
The ABAP-programs have been created with original language EN but are mostly executed with logon-language ZH.
Our development- and production-systems are still on non-unicode but our test-environments have already been successfully converted to unicode and those systems are currently used for system-testing the Unicode migration. This is where at the moment the literals are displayed as "gibberish" even if logon-language is ZH (I understand why that is: the sourcecode was converted to Unicode with original language EN).
The one thing which can be done (and what obviously should already have been done when the programs were written) is to create proper text-elements for the literals in question. But, I'm not sure that this will actually solve the issue for those cases where the programs are executed with sign-on-language EN and the literals still need to be "interpreted" as ZH - due to the fact that the values are things e.g. like names or actual constants and not really meant to be translated.
These are the examples I currently have:
1. Default value for a parameter:
PARAMETERS: P_CHECK TYPE CHAR08 OBLIGATORY DEFAULT 'ÒóÕÛºì' LOWER CASE.
2. Literal used in a comparison:
DELETE IT_ITEM WHERE FIELD20 <> '·ñ'.
What I can do is to set up text-elements - which I already did in the 2nd case (where FIELD20 is a column in an Excel-sheet which always contains Chinese text apart from a couple of lines where it's empty):
DELETE IT_ITEM WHERE FIELD20 <> '·ñ'(L01).
==> Text-element maintained with logon-language EN: L01 ·ñ
I can then logon-in with language ZH and provide the "translation" via transaction SE63. But the value provided via the text-element is of course not really correct for logon-language EN - but I don't have an English equivalant I could use either and the processing still working as intended. Kind of a catch-22!
Short of setting the language to ZH at the start of the program regardless of logon-language, is there anything else that could be done in these cases? If possible, I'd like to come up with one or two example solutions which can then be applied as needed. For the time being - until we go live with the unicode migration later this year - the solution has to work in UC- and NON-UC environments.
Thanks much!