Hi,
IMHO, use of testtool for release sanity check is time consuming.
The tool is, indeed, useful to find regression bugs at the stage of
development. It, however, in general, cannot find localization related
bugs since it is naturally language-neutral.
For resource files *.res, which reside in the directory program/resource/,
are normally created regardless of existence of localized text since
if a desired localized text is missing, then a fallback text, normally
en_US, is automatically used as an alternative.
Thus, there could be a situation where *.res files exist, but their texts
are not localized or are mistranslated. This type of situation cannot be
found by the testtool.
How can we find such a situation?
IMHO, manually testing release candidates by native language specking
persons would be the most effective way for release sanity check of localized
versions. Thus, Cor Nouws's conclusion is on the right truck, I guess.
Cor Nouws wrote:
> So I conclude it is OK to check;
> - installation;
> - some localized dialogs;
> - some autocorrect/autotext;
> - some help content;
> - language settings as time and separator.
Is there high possibility where one of or a few *.res files are physically
broken while most of *.res files are correctly created? If so, testtool
might be helpful.
But, running testtool more than 24 hours for release sanity check does
not make sense, I think.
Regards,
Tora
Joost Andrae wrote:
yes. This way it's less time consuming to check dialog resources.
- localized dialogs need to be accessed to assure that resource files
- are OK. Otherwise the application would crash
You have been saying so. IIRC "wrong resource file can crash OOo"
or soemthing like that.
IMHO In this case running VCLTestTool is a good one. what do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
