• Replies 4 replies
  • Subscribers 63 subscribers
  • Views 1786 views
  • Users 0 members are here
Options
Related

Using the Passolo ODBC parser for Excel spreadsheet translation?

Mark Owens

Hi

Has anyone been using the ODBC Add-on to translate spreadsheets instead of using the Excel Add-on? 

Here's my scenario:

I've got a multi-sheet spreadsheet file. Each sheet contains the source translations for a single language. Due to the way the product text export is configured, each sheet typically will have a different number of rows to translate, although the column formats are the same in each sheet. The source spreadsheet only ever contains strings not previously translated, so I've been creating a new Passolo (2018) project for each outsource event instead of simply updating a standard project.

My current method for working with this input spreadsheet is to:

  1. Create a new Passolo project and add the 15 target languages.
  2. Split the spreadsheet into separate spreadsheets, by sheet name
  3. Import into my Passolo project.
  4. Configure the column to translate etc using the Excel Add-on.
  5. Delete the unrequired strings lists for each language.
  6. Process the strings lists as per any other project.

I'd be interested in anyone's opinion on my existing process and/or if the above process can be improved and simplified by using the ODBC Add-on, and will it avoid doing the spreadsheet splitting/string list deletion in Passolo.

Thanks

Mark
Rate translation
×
Suggest better translation
×
Parents

  • It would be good to get at least a very small example of the Excel that you are currently processing. Just to assess the efficiency of the process you described. I assume that it can be optimized.

    Technically there is a big difference. The ODBC add-on is relying on OLE DB drivers from the operating system and as far as I know Microsoft never upgraded the OLE DB drivers for Excel to be fully Unicode compliant. So I would recommend not using ODBC for Excel if your target languages are from different codepages. The Excel component is using the Excel object model and therefore is fully Unicode compliant.
  • in reply to Achim Herrmann

    Thanks for your reply Achim. The lack of Unicode compliance is definitely a stopper for using the ODBC route, even if it  streamlined things. I've attached a sample spreadsheet with most of the rows chopped out. The spreadsheet config in the parser is:

    Start row = 2

    ID = col A

    Source text = col C

    Translation = col D

    Context = cols F & G

    Max length = col J

    passolotestspreadsheet.xlsx

    I'm interested in any suggestions you can make.

    Thanks

    Mark
  • in reply to Mark Owens

    Not a really nice formatted Excel file and I understand your issue.

    I’m not proposing to change the parser or your current setting. I would suggest to change the process assuming that the Excel file that is exported for your systems always has the same layout but different entries. So my (first) project would be:

    1. Copy the old project (with all Excel configurations and the 15 target languages)
    2. Delete the source files
    3. Add the (same) Excel file 15 times to the project (Do not split the Excel file)
    4. Configure the common source settings for all 15 source files at once
    5. Configure each source sheet name separately
    6. Configure the column to translate for all translation lists at once
    7. Delete the unrequired translation lists

    Then process the translation. When the Excel file is exported for the next translation round it will be much simpler:

    1. Copy the old project
    2. If your Excel file name changes every time, rename the source and target file name in the project using the macro PslReplaceProjectPathSelected.bas
    3. Update the project. This will reuse all settings and languages, but will delete all old source strings, due to new IDs exported from your system. Then it will add all newly exported entries

    That’s it. Now start to translate.
  • in reply to Achim Herrmann

    Ah, I see what you're doing.

    I think that would simplify things quite a bit after doing the initial config setup.

    I guess the deletion of the old source strings is a permanent thing so the project size should not become too unwieldy over time.

    Thanks for the great suggestion! 
Reply Children
No Data