none
Suggestions on complex Word template in different languages RRS feed

  • Question

  • Hi,

    I'm devoloping an Office (2007 and later) solution that makes use of a quite compex Word template (about 900 KB).

    The interface (ribbon, dialogs, messages, etc.) I wrote was in Italian; now I decided to create an English version.

    It's not necessary that the user is able to switch from one language to the other at run time; I will have two different files (templates) and the user would decide at setup which language to install.

    I'm following this strategy.

    I'm finding in my modules (cls and mod) all the phrases that need to be traslated and replace them with constants; then I put the constants in two different modules with traslations; I will compile the project with one or other of this two modules. [If I would decide to add another languages, I need only to create a third module].

    I'm having some doubts for my forms (frm). Which of the two following solutions is better?

    1. For every form, at opening event,  set the right caption for every label (using constants to the desidered language).
    2. For every form, having a duplicate in the other language and let a simple function to call the right name based on the language used.

    I think that the 1) solution is more consistent with the one used in the other modules; it is easier to implement other languages (if desidered); it is lighter in term of bytes.

    The 2) solution allows me a better looking interface because it's free of traslation constraints; It's much heavier in term of bytes.

    Could you help me with any suggestions on the subject?

    Lauro

    Friday, August 4, 2017 4:56 PM

Answers

  • Hi Lauro,

    >> are you sure you are not confusiong my 1 and 2 solutions?

    I think I understand your solutions, first is initialize the Form UI with the right language on Form open event, second is create different forms with different language, and then call the right Form with the language. Am I right?

    In my option, per to the Extensibility, I prefer the first one which could achieve your requirement. And while you want to add new other language, you just need to add the language support. If you use the second option, you will need to crate the forms again and again, and if you want to change anything in the form, you will need to change them in different forms. But for the first option, you just need to change the only one Form.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by Lauro2 Wednesday, August 9, 2017 3:02 PM
    Wednesday, August 9, 2017 7:57 AM

All replies

  • Hello Lauro,

    Why do you think it is unnecessary that users could switch language? If users want to install two language packages, how do you want users have a switch?

    If you don't allow users to install several language packages at the same time and you don't want to add a third language, I think your first solution is better.

    If you want to add a third language or more and users are able to install several language packages and easily switch, I think the second solution is better. There is no need to create duplicated forms, you could create a simple function to return right name based on language used at Form_Initialize event.

    Regards,

    Celeste


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, August 7, 2017 2:13 AM
    Moderator
  • Hi Celeste, thank you very much for your answer. If my user will decide to change language, he/her should reinstall... Of course I would like better to give the user the ability to switch at will between languages while running the application. I was restraining to the choice between languages only at install time only because I was fearing the difficulties of the other solution. For instances, I should be able: 1) to switch ribbon at run time; 2) to have the litteral constants not in module but in a file(?), dll (?), other resource (?) to use (and change) at run time. 3) to have the same file (same name) for my Word template and my Access front and back end files. 4) ... something else? When you speak of language packages, what do you have in mind exactly? Regarding the form solutions, are you sure you are not confusiong my 1 and 2 solutions? I was thinking that if I wanted to use several languages it was better to use one form with several languages packages to use at initialization time; if I was using only two languages to use two "different" forms. I don't understand you lasting remark. Are you saying I should use the Form_Initialize event to change (according to language) the labels of the form? [That was my first solution]. Thanks again, Lauro
    Monday, August 7, 2017 8:29 AM
  • Hi Lauro,

    >> are you sure you are not confusiong my 1 and 2 solutions?

    I think I understand your solutions, first is initialize the Form UI with the right language on Form open event, second is create different forms with different language, and then call the right Form with the language. Am I right?

    In my option, per to the Extensibility, I prefer the first one which could achieve your requirement. And while you want to add new other language, you just need to add the language support. If you use the second option, you will need to crate the forms again and again, and if you want to change anything in the form, you will need to change them in different forms. But for the first option, you just need to change the only one Form.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by Lauro2 Wednesday, August 9, 2017 3:02 PM
    Wednesday, August 9, 2017 7:57 AM
  • Thank you Edward for your answer.

    Yes you understood well my intentions. I agree with you: the first solution is better.

    Now I'm struggling with

    1.  How to change ribbon at run time.
    2. How to build (and use) a resource only DLL to store my strings.

    Ciao Lauro

    Wednesday, August 9, 2017 3:01 PM
  • Hi Lauro2,

    For these two new issues, I would suggest you post two new threads for them, then we could focus on discussing them, and provide more solid suggestion against the issue.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, August 10, 2017 1:20 AM