2016 Feb 29 3:37 PM
Hello,
Our business is using an output type for delivery for the Romania region. The printout comes in Romanian language .Now they want to re-use the same smart form for the Serbia market.
The delivery print out has the customer name in the header , material desc, qty, batches and other information in the body and salutations etc in the footer.
I need to know how can we do the language conversion for all the above for the Serbian market using the Romania form ?.
1) do we need to maintain the customer name in serbian language in the customer master or can we do it in the form ?
2) What about material description. will the conversion in Serbian language be done in the form or we need to maintain the serbain language for the material description in the material master ? how do we tell the system to print in Serbian or Romanian language ?
3) how does the sap log on language effect the language conversion.. For eg if we log into sap with serbian language, do we need to use the Serbian language conversion in the smartform ? I mean logging into sap with Serbian language should automatically display the language in Serbia in the form
4) there are two languages, one is logn on langague (sy) and output language (NAST table). How these effect form printing in local language ?
would request someone to clarify how language conversion happens in SAP for the forms
regards
sachin
2016 Feb 29 4:05 PM
It will depend..
Forms are usually triggered to print in a certain language (cfr NAST-SPRAS) 'defined' on the output and thus not depended on the user/logon language (SY-LANGU). The first will trigger the translation, but it is possible to circumvent through code (though I'd advise against it).
As far as texts like material descriptions go, normally these are defined on the material, and translating them in the form (by hard coding) would quickly get messy. So via material master is the way to go.
The texts in the form itself (like labels etc) you can maintain/translate through transaction SE63.
2016 Feb 29 4:05 PM
It will depend..
Forms are usually triggered to print in a certain language (cfr NAST-SPRAS) 'defined' on the output and thus not depended on the user/logon language (SY-LANGU). The first will trigger the translation, but it is possible to circumvent through code (though I'd advise against it).
As far as texts like material descriptions go, normally these are defined on the material, and translating them in the form (by hard coding) would quickly get messy. So via material master is the way to go.
The texts in the form itself (like labels etc) you can maintain/translate through transaction SE63.
2016 Feb 29 4:20 PM
Hello Parick,
thanks for the quick reply. If we maintain translation in material master in Serbian and Romanian language, do we get both the languages in the smartform in the program or will it depend on which logon language we are logged into ?
that is if we log into serbain language in sap, then the Serbian language material desc from
material master will be available in smartform ? is this correct ?
maintaining output language=Serbian in output type will print serbain in the form even if we do not mainatain material desc in material master ?
how is SE63 and SO10 differ ? can you explain by an example pls ?
Iam reaaly not sure how all the language conversion works. Can you pls clarify ?
regards
sachin
2016 Feb 29 4:33 PM
If both languages are maintained you'd see in material description in the logon language in MM03 for instance..
Normally, the material description in the smartform should depend on the language in which the document is printed (and not the logon language). But, there are little guarantees since I've encountered quite a few forms already where the material texts were read with select singles statements and sy-langu as a selection parameter (or with no language parameter at all).
But in any case, it would be absurd to start translating stuff in the form itself.
As far as the comparison goes (lmgify):
Transaction SE63 - Translation Tools for Translators (BC-DOC-TTL) - SAP Library
Also, this may be of assistance:
Smart Form Language Translation - Step by Step procedure - ABAP Development - SCN Wiki
2016 Mar 02 11:15 AM
Hello,
for having the form in other languages you should consider two things.
First is translating the form from original language and second is control printing.
Control printing can be maintained through customer setup (you are printing in customer language setup in XD03) or you can printout in logon language. In any case you can maintain this in variety of scenarios.
About translation.
You should discover all elements which are coming on the form. This can be data element, can be SO10 Text, can be Smartform text inside the smartform, also can be text module from the smartform and so on...
Once you get all object you can translate them and check if translation is already in the system.
You can not compare SO10 and SE63. SO10 transaction is transaction for making SO10 Text. This is an object which is not translatable. To make it clear. When you make one XYZ SO10 Text in English, you can not translate this object in to Serbian. You have to create another object with the same name but in Serbian language. This two objects are not connected. Also SO10 is technology from sap script.
Smartform have "Text module" for this purpose and the differences is, that this object is translatable.
SE63 is transaction for translating objects.In this transaction you can translate also Smartform and Smartfom text module (SSF is the type of the object). Also you can translate all other objects as well, but not SO10 (because as I have mention before, this object is not translatable.
So, first step is list of the objects which are on the form.
Check translation in the system and when everything is ok, printing.
I hope this help.
2016 Feb 29 4:30 PM
Hello Patrick,
I hope you are aware that we need to use the same form for Serbia and Romania !
I hope by label you mean descriptions like, Qty etc in the form. So we can maintain the translation for the same in Se63 for serbain and Romanian language. and in the form we put a condition that if sales org=serbain, then use the translation accordingly and if sales org=Romanian, then use translation accordingly. ? IS this right ?
thirdly if we do maintain any translation, then if the output language is Serbian, then system should auto convert all the text, labels etc in Serbian ? is this correct ? if not, then what is the use of maintaining output langaugae?
regards
sachin
2016 Feb 29 4:37 PM
Like I said in the previous post, it would depend on how the form is build as well. But texts translated through SE63 are translated automatically.
Material descriptions (etc) it will depend on how these are selected/ read from the dbase..
2016 Feb 29 5:02 PM
thanks Patrick,
Last question. what is the difference between text and label in a smartform.
column headings like "Material number", qty, Price" are text or lables ?
Fixed footer details like Company name are texts or labels ?
regards
sachin
2016 Feb 29 8:01 PM
Hmm.. tricky question. But I consider nearly all of them as texts. They can have different sources though. The footer details can be OTR, SO10 or hard coded texts for instance (and there are several other possibilities).
In your example, the column headings would be translated via the form per transaction SE63 ( but you might also consider to get the label from DDIC). The fixed footer I would set up (and translate) as either an SO10- (or OTR-) text (that way they can be maintained without having to change the form, and there is the re-use possibility in other forms).
Bottom line, a header of a column is can of course be described a label, but in the end it remains a text in the form
I've seen forms where all texts and labels are maintained (&translated) in tables, SO10 texts and no texts at all in the form. Which works perfectly well (but it tends to make the form 'unreadable' as a developer if you want to know what happens where in the event you have to make some changes later on).
Anyway, if I can re-use a text (whatever it may be) in several other forms then I consider creating it outside the form. Else I keep it in the form. But that is my logic, and there are probably a lot of people that have different standards.
2016 Feb 29 5:18 PM