Dear Stefan.
Dear translators.
As this 'report' tool I suggest to have may affect every translators you
suggestion is more then welcome.
>
> I don't think php would be the right tool for this kind of job.
OK. We will look for alternatives and make decision later.
>
> 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.
101% right !
>
> 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.
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 ?
>
> How to solve this problem:
> There are of course different ways to solve this problem.
And may be much more :)
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?
From my point of view this solve only step 1. (see bellow)
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 ?
> - 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 ?
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?
> - 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.
>
>
>
> 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?
>
>
> 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 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)
PS: Thanks lot for your time.
--
Oto BREZINA
SW R&D Manager
Printflow, Slovakia EU
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Sep 15 21:42:25 2007