Oto BREZINA wrote:
>> 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.
>
> Yes this seems be a correct rewrite of my problem.
> How you keep watch on English accelerators only as is "naturally"
> grouped you check it when writing ?. Do you anytime use different
> accelerator for same string ?
I add the accelerators as I see fit. Usually when I check a dialog, I
see all the accelerator keys and if some controls don't have one, I add
one that isn't used in the same dialog. I don't pay attention to whether
that string is used elsewhere with a different accelerator.
> Let's call it A1 (alternative 1)
>> * 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
> Because I personally use poEdit I would not preffer this.
> Another Problem I see is that it will (if I understand properly)
> "doubled" strings so it will change .po files. I would like not "attack"
> translators who do not care, or even add more work to them by duplicate
> string. Here is also problem that .po do not support duplicates.
> Side question: How Luebbe test overlaping acc. keys in DE translation?
He doesn't. The only real test is to actually use TSVN and try it out.
> Let's call it A2 (alternative 2)
>> * 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
> what you mean by "many separate files" here ?
there are more than just one rc file in TSVN.
>> - Translators still have to check their strings manually
> See step 1 bellow.
> Also in .rc there are lines CAPTION "About TortoiseSVN" so translator
> can identify/imagine where this group appear. Is this possible from
> ResText ?
That's the dialog title. Yes, it would be possible to check whether a
string is from a dialog title or not.
> Let's call it A3 (alternative 3)
>> * 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.
> Yes, but has overlaping acc keys more sense than missing one ? When you
> don't see acc key you will not use it, but when you see one, ans it do
> something different because there is another function with same keys it
> is not to much user-frendly, or?
Now that's not true. An accelerator key will never just execute another
function than what you would have expected. If there are more than one
identical accelerator key, you can hit that key multiple times without
executing the function(s). All you will do is to toggle between the
controls with that accelerator key, setting the focus to those controls.
Now, if that's why you're so worried about duplicate accelerator keys
and that's the reason you want this feature, then I guess you should
reconsider. It's not really a big problem to have duplicate accelerator
keys - it won't do any harm.
And as I mentioned before, I'm not so keen about implementing such a
feature for so less gain.
>> - 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, ...
> Basically yes. But may be some uncommon string don't need acc. key.
Well, how do you define 'uncommon'?
>> 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).
> I don't like first solution because one of my request when I build this
> task was not add work to translation by changing .po. I would only like
> to have tool - report.
> I don't need webpage report but it looks for me as easiest solution
> because of .php and text only data. (.php can generate also mails). Side
> question: How are Mondays report generated?
Monday reports are generated by a nice tool called Lübbe :)
>> Comments? Volunteers for changing ResText or creating a script?
> Change ResText to generate group list I see as first task (in case we
> would not use A3)
> Compare and assign proper acc.keys may be in first stage on translator
> neck.
> Later we may decide to which way is right to make reports.
I won't implement a feature just to have *later* decided on how to
actually use it.
> I see it as tristep solution.
>
> 1. Make/take inputs files to make groups file(s).
> A. Files we may use:
> B. ResText output as modified .po/.pot file
> C. ResText output as group file(s)
> D. .rc directly or reparsed
>
> 2. Compare group list to translation.
> A. do it within poEdit
> B. integrate to ResText to use in translation build time (don't need
> step 1)
> C. external script
> D. Manually by translators
>
> 3. Generate/output report.
> A. email
> B. file in night build
> C. web
> !Note! this can be an online tool so anybody can test translation
> before commint and only succesive assign will go to svn server. This
> give me an idea of making such tool on my server. (Still need step 1)
I think you're going a little overboard here. An online tool to check
for duplicate accelerator keys even before you commit?
If you really want to test this, you could use ResText to apply your
translation to the latest nightly builds, and then you could use a
resource editor tool like this one:
http://www.wilsonc.demon.co.uk/d10resourceeditor.htm
to show every dialog and menu separately. Just make sure that each
dialog or menu doesn't have duplicate accelerator keys.
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
Received on Sun Sep 16 18:17:58 2007