Update descriptions in uefiController.strings (en), Added ForceBooterSignature...

Update descriptions in uefiController.strings (en), Added ForceBooterSignature key and description in booterController (zh-Hant)

@bluehomewu Please localize for ForceBototerSignature description.

Chinese, Traditional Localization (zh-Hant)/Sections/booterController.strings

@@ -149,6 +149,9 @@
 /* Class = "NSButtonCell"; title = "ProtectSecureBoot"; ObjectID = "rWG-6j-Mxs"; */
 "rWG-6j-Mxs.title" = "ProtectSecureBoot";
 
+/* Class = "NSButtonCell"; title = "ForceBooterSignature"; ObjectID = "sHw-qr-Pag"; */
+"sHw-qr-Pag.title" = "ForceBooterSignature";
+
 /* Class = "NSButtonCell"; title = "SetupVirtualMap"; ObjectID = "sNx-S4-Yhl"; */
 "sNx-S4-Yhl.title" = "SetupVirtualMap";
 
@@ -158,6 +161,9 @@
 /* Class = "NSButton"; ibShadowedToolTip = "Type: plist boolean\nFailsafe: false\nDescription: Provide custom KASLR slide on low memory.\nThis option performs memory map analysis of the firmware and checks whether all slides (from 1 to 255) can be used. As boot.efi generates this value randomly with rdrand or pseudo randomly rdtsc, there is a chance of boot failure when it chooses a conflicting slide. In case potential conflicts exist, this option forces macOS to use a pseudo random value among the available ones. This also ensures that slide= argument is never passed to the operating system for security reasons.\nNote: The necessity of this quirk is determined by OCABC: Only N/256 slide values are usable! message in the debug log. If the message is present, this option is to be enabled."; ObjectID = "wGH-hP-xhD"; */
 "wGH-hP-xhD.ibShadowedToolTip" = "是否使用slide值。一般選擇連續性注入記憶體並配合slide，所以選擇YES。\nBat.bat解释:\n如果 Slide 值存在衝突, 此選項將強制 macOS 執行以下操作:\n使用一個偽随機值。 只有在遇到 Only N/256 slide values are usable! 時需要。";
 
+/* Class = "NSButton"; ibShadowedToolTip = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property."; ObjectID = "woE-nK-MFN"; */
+"woE-nK-MFN.ibShadowedToolTip" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
+
 /* Class = "NSTableColumn"; headerCell.title = "Limit"; ObjectID = "xEr-hF-nBr"; */
 "xEr-hF-nBr.headerCell.title" = "限制";
 

English Localization (en)/Sections/uefiController.strings

@@ -413,8 +413,8 @@
 /* Class = "NSTextFieldCell"; title = "ExitBootServicesDelay"; ObjectID = "wxD-TC-lrQ"; */
 "wxD-TC-lrQ.title" = "ExitBootServicesDelay";
 
-/* Class = "NSTextField"; ibShadowedToolTip = "Type: plist integer\nFailsafe: 0\nDescription: Remove key unless it was submitted during this timeout in milliseconds.\n\nAppleKeyMapAggregator protocol is supposed to contain a fixed length buffer of currently pressed keys. However, the majority of the drivers only report key presses as interrupts and pressing and holding the key on the keyboard results in subsequent submissions of this key with some defined time interval. As a result we use a timeout to remove once pressed keys from the buffer once the timeout expires and no new submission of this key happened.\n\nThis option allows setting this timeout based on the platform. The recommended value for the majority of platforms is 5 milliseconds. For reference, holding one key on VMware will repeat it roughly every 2 milliseconds and the same value for APTIO V is 3-4 milliseconds. Thus, it is possible to set a slightly lower value on faster platforms and a slightly higher value on slower platforms for more responsive input.\n\nPressing keys one after the other results in delays of at least 6 and 10 milliseconds for the same platforms.\n\nNote: Some platforms may require different values, which may be higher or lower. For example, when detecting key misses in OpenCanopy, try increasing this value (e.g. to 10), and when detecting key stall, try decreasing this value. Since every platform is different, it may be prudent to check every value from 1 to 25."; ObjectID = "xNH-9V-3kd"; */
-"xNH-9V-3kd.ibShadowedToolTip" = "Type: plist integer\nFailsafe: 0\nDescription: Remove key unless it was submitted during this timeout in milliseconds.\n\nAppleKeyMapAggregator protocol is supposed to contain a fixed length buffer of currently pressed keys. However, the majority of the drivers only report key presses as interrupts and pressing and holding the key on the keyboard results in subsequent submissions of this key with some defined time interval. As a result we use a timeout to remove once pressed keys from the buffer once the timeout expires and no new submission of this key happened.\n\nThis option allows setting this timeout based on the platform. The recommended value for the majority of platforms is 5 milliseconds. For reference, holding one key on VMware will repeat it roughly every 2 milliseconds and the same value for APTIO V is 3-4 milliseconds. Thus, it is possible to set a slightly lower value on faster platforms and a slightly higher value on slower platforms for more responsive input.\n\nPressing keys one after the other results in delays of at least 6 and 10 milliseconds for the same platforms.\n\nNote: Some platforms may require different values, which may be higher or lower. For example, when detecting key misses in OpenCanopy, try increasing this value (e.g. to 10), and when detecting key stall, try decreasing this value. Since every platform is different, it may be prudent to check every value from 1 to 25.";
+/* Class = "NSTextField"; ibShadowedToolTip = "Type: plist integer\nFailsafe: 0\nDescription: Remove key unless it was submitted during this timeout in 10 ms units.\n\nAppleKeyMapAggregator protocol is supposed to contain a fixed length buffer of currently pressed keys. However, the majority of the drivers only report key presses as interrupts and pressing and holding the key on the keyboard results in subsequent submissions of this key with some defined time interval. As a result we use a timeout to remove once pressed keys from the buffer once the timeout expires and no new submission of this key happened.\n\nThis option allows setting this timeout based on the platform. The recommended value for the majority of platforms is 5 (50 milliseconds). For reference, holding one key on VMware will repeat it roughly every 20 milliseconds and the same value for APTIO V is 30-40 milliseconds. Thus, it is possible to set a slightly lower value on faster platforms and a slightly higher value on slower platforms for more responsive input.\n\nPressing keys one after the other results in delays of at least 60 and 100 milliseconds for the same platforms.\n\nNote: Some platforms may require different values, which may be higher or lower. For example, when detecting key misses in OpenCanopy, try increasing this value (e.g. to 10), and when detecting key stall, try decreasing this value. Since every platform is different, it may be prudent to check every value from 1 to 25 (10 to 250 milliseconds)."; ObjectID = "xNH-9V-3kd"; */
+"xNH-9V-3kd.ibShadowedToolTip" = "Type: plist integer\nFailsafe: 0\nDescription: Remove key unless it was submitted during this timeout in 10 ms units.\n\nAppleKeyMapAggregator protocol is supposed to contain a fixed length buffer of currently pressed keys. However, the majority of the drivers only report key presses as interrupts and pressing and holding the key on the keyboard results in subsequent submissions of this key with some defined time interval. As a result we use a timeout to remove once pressed keys from the buffer once the timeout expires and no new submission of this key happened.\n\nThis option allows setting this timeout based on the platform. The recommended value for the majority of platforms is 5 (50 milliseconds). For reference, holding one key on VMware will repeat it roughly every 20 milliseconds and the same value for APTIO V is 30-40 milliseconds. Thus, it is possible to set a slightly lower value on faster platforms and a slightly higher value on slower platforms for more responsive input.\n\nPressing keys one after the other results in delays of at least 60 and 100 milliseconds for the same platforms.\n\nNote: Some platforms may require different values, which may be higher or lower. For example, when detecting key misses in OpenCanopy, try increasing this value (e.g. to 10), and when detecting key stall, try decreasing this value. Since every platform is different, it may be prudent to check every value from 1 to 25 (10 to 250 milliseconds).";
 
 /* Class = "NSTextField"; ibShadowedToolTip = "Type: plist integer\nFailsafe: 0\nDescription: Adds delay in microseconds after EXIT_BOOT_SERVICES event.\n\nThis is a very rough workaround to circumvent the Still waiting for root device message on some APTIO IV firmware (ASUS Z87-Pro) particularly when using FileVault 2. It appears that for some reason, they execute code in parallel to EXIT_BOOT_SERVICES, which results in the SATA controller being inaccessible from macOS. A better approach is required and Acidanthera is open to suggestions. Expect 3 to 5 seconds to be adequate when this quirk is needed."; ObjectID = "yXm-Kd-A6O"; */
 "yXm-Kd-A6O.ibShadowedToolTip" = "Type: plist integer\nFailsafe: 0\nDescription: Adds delay in microseconds after EXIT_BOOT_SERVICES event.\n\nThis is a very rough workaround to circumvent the Still waiting for root device message on some APTIO IV firmware (ASUS Z87-Pro) particularly when using FileVault 2. It appears that for some reason, they execute code in parallel to EXIT_BOOT_SERVICES, which results in the SATA controller being inaccessible from macOS. A better approach is required and Acidanthera is open to suggestions. Expect 3 to 5 seconds to be adequate when this quirk is needed.";