[Bug 51619] New: advapi32:registry fails in Wine because a German timezone name translation is too long

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51619

            Bug ID: 51619
           Summary: advapi32:registry fails in Wine because a German
                    timezone name translation is too long
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: advapi32
          Assignee: wine-bugs at winehq.org
          Reporter: fgouget at codeweavers.com
      Distribution: ---

advapi32:registry fails in the timezone tests in a German locale:

registry.c:4339: Test failed: L"Aus Central W. Standard Time": expected
L"West-Zentralaustralische Normalzeit", got L"Aus Central W. Standard Time"
registry.c:4357: Test failed: L"Aus Central W. Standard Time": expected
L"West-Zentralaustralische Sommerzeit", got L"Aus Central W. Daylight Time"

https://test.winehq.org/data/patterns.html#advapi32:registry

The reason is that the test compares the localized obtained through the
registry with the one obtained through EnumDynamicTimeZoneInformation(). But
the latter translation must fit into a 32 character buffer: WCHAR
StandardName[32].

However Wine's German translation is too long (36 character including the
trailing '\0'), causing EnumDynamicTimeZoneInformation() to return the
untranslated string instead.


Potential fixes
---------------

1. Only compare the values if they fit in the {Daylight,Standard}Name buffer.
   - That means Windows applications will not get a translated timezone name
     which is bad.
   - This prevents detecting further issues.
   - It's unclear if returning an untranslated string is the right thing for
     EnumDynamicTimeZoneInformation() to do: I did not find a case (at least
     in German where a translation did not fit).

2. Modify EnumDynamicTimeZoneInformation() to return a truncated translation
   instead of an untranslated string.
   - Windows applications will get a not quite correct timezone name.
   - Also we would need evidence that this matches the Windows behavior.

3. Modify the German translation.
   - This side-steps the issue and may be the best solution.
   - But I doubt one can find a shorter translation that fits, short of
     using ellipses which is not great.


Detecting / Preventing recurrences
----------------------------------

1. It would be nice to be able to include a translator warning about this
   issue. I'm not sure how to do so in dlls/tzres/tzres.rc.

2. The current tests are insufficient to detect further issues
   - To detect every issue they would have to be run in every locale.
   - Or going forward, whenever a PO file is modified they would need to be
     run in that locale.
   - Maybe issues could be detected by calling RegLoadMUIStringW() for every
     timezone and locale combination. However it does not take an LCID which
     makes this complicated.

3. Write a script checking the PO files.
   - This seems like the simplest option to detect issues.
   - When to run it? Manually? Automatically from the makefiles?

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.