Re: Accelerator key problem in translation

Oto BREZINA wrote:
> Dear Stefan,
>
> It seems we are on right track ...
>
> Stefan Küng wrote:
>>
>> I don't like the idea of parsing the rc file. Because that's not
>> necessary and TortoiseProc uses *two* rc files to get its resources from.

> I don't like people who don't like do thinks in my way :D no really If
> there is another way I'll like it - this was just idea ...
> .rc parsing advantage is it will not need any extra tool. It may be
> implementing easily in let say .php.

I don't think php would be the right tool for this kind of job.

But before we go any further here, lets first write down all the
requirements. It seems to me that we're not talking about the same
things here, and its important that we do.

So, here's how I understand what you want:

When translating the resources (strings, menus, dialogs, ...), some of
the resources have accelerators (e.g., &Copy, &Open, R&evision, ...).
Those accelerators get of course translated too. The problem is that
there's currently no way of knowing which of the resources belong
together, i.e., are used in the same menu, dialog, ... and therefore no
way of knowing if an accelerator key is used twice or more in the same
context.
The tool we use to extract and apply the resource strings doesn't group
the resource strings together.
po-files (the files used by the translators) don't know about groups either.

How to solve this problem:
There are of course different ways to solve this problem.

* change ResText to output the resource strings in the po-file grouped
   together. This change would not be very hard to do. Since po-files
   don't know 'groups', we could list the strings for every group, then
   add one or two more empty lines before the next group starts. And
   maybe add a comment to each resource entry in the form
   # Resource group <dialog 1>
   Translators then could determine from the po file which strings belong
   together (all with the same 'group comment').
   Advantage: not very hard to implement (change the std::map<> to an
   std::vector<>, change the po-save() function to include the groups)
   Problems: - Translators would have to check themselves which strings
               belong into which group
             - po-Editors (e.g., poEdit) won't keep the double/tripple
               empty lines between the groups, so the group-formatting
               will only be available in the pot file
* parse the *.rc files directly and generate a file which maps all the
   strings into groups. This could be done with a separate script.
   Advantage: - using scripts means no change to ResText itself
              - separate output files for the groups means no problems
                with po editors
   Problems: - many separate files to go through
              - Translators still have to check their strings manually
* generate a report which contains all the strings in a group and which
   group has two or more identical accelerator keys. The report could be
   generated by using either the 'grouped' pot-file (see above) or by
   using the output file of the parsing script (see above). Or it could
   be done in ResText itself while applying the translated resources:
   each resource is applied in a 'group' anyway (applying the resources
   is done dialog by dialog, menu by menu, ... - which means ResText
   could check the accelerator keys for every group it applies and print
   out a warning if a group contains two or more strings with the same
   accelerator key).
   Advantage: - we could set up a weekly report for all translators to
                check.
   Problems: - the reports won't be of much help to the translators,
                because there are some dialogs where it is simply
                impossible to *not* have two identical accelerator keys
                because there are so many of them (e.g., merge dialog).
                The report will therefore *always* have warnings in it.
              - Using ResText to generate the report is very expensive,
                because applying the resources uses a lot of CPU.

All these (except the first suggestion) have one big problem in common:
Many strings are used in several places (e.g. "HEAD Revision"). Solving
a duplicate accelerator key by changing such a string will most likely
create the same problem in a different dialog, menu, ...

I would prefer the first solution to this problem. And maybe later we
could change ResText even more to generate a warning report when
applying the translated resources. That way, we could get a 'report'
with every nightly build (of course, that means the translators would
have to read that report from the nightly build folder, not directly on
a nicely formatted webpage).

Comments? Volunteers for changing ResText or creating a script?

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org