u_dzFileUtils raises EOSError through RaiseLastOsErrorEx in 17 places, with 12 different message texts that all say the same thing in slightly different words:
TFileSystem.GetTempPath: %1:s (code: %0:d) calling Windows.GetTempPath, and the same for GetTempFileName and GetShortPathname, with code: and Code: mixed%1:s (code %0:d) calling Windows.GetFullPathNameError %1:s (%0:d) calling %s (PathCanonicalize)Error %1:s (%0:d) creating directory "%s", ... deleting file "%s", ... deleting directory "%s"Error %1:s (%0:d) while trying to move "%s" to "%s"., ... to copy "%s" to "%s".Error %1:s (%0:d) while trying to change the date and time of "%s", ... while changing the readonly flag of "%s"Each of them is a separate string for the translators. They could be reduced to one or very few messages that take the name of the failing API (and the file names) as parameters, e.g. Error %1:s (%0:d) calling %2:s and Error %1:s (%0:d) calling %2:s for "%3:s".
That needs an overload of RaiseLastOsErrorEx that takes additional format arguments. It would also remove a weakness of the current approach: the file names are first put into the format string with Format and the result is then used as the format string for EOSError.CreateFmt. A file name containing % (which is legal) is then interpreted as a format specifier, giving an EConvertError or a garbled message instead of the EOSError.
Fixed in revision #2421