Excel Export based on the translation status

Posted by Phil on Sun 05 of Sep, 2010 22:23 GMT Germany

In version 4.7x.0035, there is a change to the Excel Export dialog.

Previously there was an option to export only "new, changed or untranslated" strings. The exact way that this worked was not really clear for users, and it was rather inflexible.

I have now replaced that option with a more general option to export texts with specific status values, as shown in the following screenshot.
Image

This is still a bit confusing, because the status is defined for each translation, but the export is filtered on a line by line basis. A line will be written to the Excel file if any translation on the line has one of the specified status values.

By the way, this logic ignores the status of the text in the original language (which is normally original text).

The logic in the previous version was equivalent to selecting all status values, except for Excel. This was based on the idea that all translations should be made - or at least checked - by an external translator. In this case, the only reliable translations are ones which have been imported from Excel. I think that that was a reasonable approach for some users, but a bit too strict for others.

Phil

Reads: 28444
Link
Posted by nickniebling on Thu 16 of Sep, 2010 09:14 GMT

Hi there Phil,

A very nice contribution to the Excel Export...

But I still believe there is room for improvement in the Excel export. Please take think about the following settings upon export:

1. Possibility to export one ID once - not once pr. control using it (Multiple usage)
Our translators have to translate "Error" many times as this is a term used several times - but actually its the same translation ID for all 20 instances - why make the translators translate this word 20 times? and we could find more examples.

2. Possibility to hide "Location" column
We are using the comment system to provide information to the translators - not the control ID etc. In our usecase, this confuses the translator more than it helps - could be nice to hide it.

3. Possibility to hide "ID" column - same as "2."

4. Possibility to hide "Multiple usage" column - same as "2."

5. Possibility to position "Comment" column to the right
As described in "2." we use comments very much. Sometimes we have long comments. It might be easier for the translator to read this if they are en doubt, so it doesn't take a lot of space to the left of the strings to be translated from/to.

I listed above prioritized - so what we need most is 1 and least 5.

I would really appreciate at least a comment or your view on above. Are we using the software "the wrong way" or do you agree this is missing functionality (and do you think it would be implemented, and do you know when)?

Thank you very much for your great software.. Still room for improvement, but you are going in the right direction all the time i think.

Yours Faithfully,
Nick Niebling

Link
Posted by Phil on Thu 16 of Sep, 2010 22:10 GMT Germany

Hi Nick,

I have never been really happy with the format of the Excel export. I have tried different things out and the result is a bit mixed up.

At present there are three different formats:

The standard formatThis has columns for Location, ID and Multiple usage.
If a string is used multiple times, then it appears multiple times in the excel worksheet.
The simple formatThis has a column for the ID.
Each string appears once only.
The structured formatThis format has three worksheets.
The first two are similar to the Controls ans Source Code tabs in the Add-In. The third is identical to the simple format (above).
This format uses macros to keep the three worksheets synchronized.

The simple format and the structured format have been moved to a submenu.

You are clearly using the standard format. My guess is that you would be better off using the simple format. If you are using the comment field consistently, then that is probably the best approach of all.

I see a fundamental conflict between these two formats.

Either

  • I show where a text is used, and export each usage separately,

or

  • I export each text once only, but so not show where it is used.


If it is important to know where a text is used, then only because it might affect the translation. In this case, the translator should have the opportunity to translate different occurrences differently.

If you are going to translate all occurrences of a text with the same translation, then why do you need to know where it is used?

I don't see a middle way between these options. Thus your points 1, 2 and 4 would go together.

The string ID is a bit different. It is the primary key which I use to import the translations. I would prefer not to do without this field.

(It would be possible to use the original text as a key, so long as it was (a)unique, (b)not changed in the Excel file and (c) not changed in the project. I'm not really keen on that approach.)

In the simple format, I think that the comment column is on the right anyway, but I could make that configurable.

Just a quick word about the structured format. I think it is a great method, but it is a failure for two reasons:

  • it is too complicated
  • it uses macros

In particular the macros mean that many many users (or organizations) will not use it. I might as well remove it completely (although I should continue to import it).

What can I change?

Please take a look at the simple format and let me know if it meets your needs.

I would actually consider scrapping both the standard format and the structured format and going back to the simple format (exclusively). It is unfortunate, that it does not show where a text is used, but the simplicity is a great strength.

If I keep the standard format, I really ought to integrate the two formats into a single dialog. In particular the import operation ought to recognize the format automatically (which I don't think it does at present).

For example, if there were two big buttons "Export simple format" and "Export with location", it would be pretty obvious that you were making an important choice.

Phil

Link

Posted by nickniebling on Mon 27 of Sep, 2010 08:57 GMT

Hi there Phil,

Thank you for the feedback - I've been off the translation for some days, but now I'm back on.

The simple view was just what I need. As you mention, this solves 3-4 of the points!

Actually I would prefer you only had 1 export to excel - defaults as simple export - and then have some configurations to add/remove columns and change the order of the columns. And some columns should of course be mandatory (like ID)!

So what I meant with "hiding" the ID column, wasn't actually to "remove" it. Excel can make 0-with columns.. Column "A" could be a "0px with column" - this will make it more simple to view (and would avoid taking up space!)

You say you cannot find a middle-way of displaying strings "multiple times + location + multiple usage" or displaying strings "only once without location". Well actually I think I have an idea that would benefit my use case scenario:
The last column (after comments - as location could have a large with) or last (multiple) columns could be used for displaying several locationS. So either a comma separated string of locations in 1 column or several columns - 1 for each different location (some will have 1, others 20). But of course with no possibility to change values!

Above would allow me to make a excel with the following columns:
- ID (zero-with)
- Lang 1
- Lang 2
- Lang n-1
- Lang n
- Multiple Usage
- Comment
- Locations (comma separated or multiple columns)

And others could make:
- ID (zero-with)
- Location
- Multiple Usage
- Lang 1
- Lang 2
- Lang n-1
- Lang n
- Comment

I will use the simple export for now - but I would be prefer a configurable excel export which will be closer to our organizations needs.

Yours Faithfully
Nick Niebling

Link