From f3a1a7b242b44842eddf39e579806bf969a96c45 Mon Sep 17 00:00:00 2001
From: debuggerx <debuggerx@debuggerx-PC>
Date: Wed, 26 Jun 2024 19:26:19 +0800
Subject: [PATCH] AI-Koala | 2024.1.1 <debuggerx@debuggerx-PC Update
 yiiguxing.translation.xml

---
 yiiguxing.translation.xml | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/yiiguxing.translation.xml b/yiiguxing.translation.xml
index d922c2d..17963c7 100644
--- a/yiiguxing.translation.xml
+++ b/yiiguxing.translation.xml
@@ -11,6 +11,9 @@
     <option name="translationDialogLocationY" value="536" />
     <option name="translationDialogWidth" value="1253" />
     <histories>
+      <item value="Translucent targets both receive events within their bounds and permit targets visually behind them to also receive events." />
+      <item value="Opaque targets can be hit by hit tests, causing them to both receive events within their bounds and prevent targets visually behind them from also receiving events." />
+      <item value="Targets that defer to their children receive events within their bounds only if one of their children is hit by the hit test." />
       <item value="The number of device pixels for each logical pixel. This number might not be a power of two. Indeed, it might not even be an integer. For example, the Nexus 6 has a device pixel ratio of 3.5." />
       <item value="Whether this range is empty (but still potentially placed inside the text)." />
       <item value="The index of the first character in the range. If [start] and [end] are both -1, the text range is empty." />
@@ -58,14 +61,11 @@
       <item value="The minimum insets for contents of the Scaffold to keep visible." />
       <item value="The minimum viewPadding for interactive elements positioned by the Scaffold to keep within safe interactive areas." />
       <item value="If true the [body] and the scaffold's floating widgets should size themselves to avoid the onscreen keyboard whose height is defined by the ambient [MediaQuery]'s [MediaQueryData.viewInsets] `bottom` property. For example, if there is an onscreen keyboard displayed above the scaffold, the body can be resized to avoid overlapping the keyboard, which prevents widgets inside the body from being obscured by the keyboard. Defaults to true." />
-      <item value="The number of physical pixels on each side of the display rectangle into which the view can render, but over which the operating system will likely place system UI, such as the keyboard, that fully obscures any content. When this property changes, [PlatformDispatcher.onMetricsChanged] is called. When using the Flutter framework, using [MediaQuery.of] to obtain the insets (via [MediaQueryData.viewInsets]), instead of directly obtaining the [viewInsets] from a [FlutterView], will automatically cause any widgets dependent on the insets to rebuild when they change, without having to listen to [PlatformDispatcher.onMetricsChanged]. The relationship between this [viewInsets], [viewPadding], and [padding] are described in more detail in the documentation for [FlutterView]. See also: [WidgetsBindingObserver], for a mechanism at the widgets layer to observe when this value changes. [MediaQuery.of], a simpler mechanism for the same. [Scaffold], which automatically applies the view insets in material design applications." />
-      <item value="The [padding] property is computed from both [viewInsets] and [viewPadding]. It will allow a view inset to consume view padding where appropriate, such as when a phone's keyboard is covering the bottom view padding and so &quot;absorbs&quot; it. Clients that want to position elements relative to the view padding regardless of the view insets should use the [viewPadding] property, e.g. if you wish to draw a widget at the center of the screen with respect to the iPhone &quot;safe area&quot; regardless of whether the keyboard is showing. [padding] is useful for clients that want to know how much padding should be accounted for without concern for the current inset(s) state, e.g. determining whether a gesture should be considered for scrolling purposes. This value varies based on the current state of the insets. For example, a visible keyboard will consume all gestures in the bottom part of the [viewPadding] anyway, so there is no need to account for that in the [padding], which is always safe to use for such calculations." />
-      <item value="The parts of the display that are completely obscured by system UI, typically by the device's keyboard. When a mobile device's keyboard is visible `viewInsets.bottom` corresponds to the top of the keyboard. This value is independent of the [padding] and [viewPadding]. viewPadding is measured from the edges of the [MediaQuery] widget's bounds. Padding is calculated based on the viewPadding and viewInsets. The bounds of the top level MediaQuery created by [WidgetsApp] are the same as the window (often the mobile device screen) that contains the app. {@youtube 560 315 https:www.youtube.comwatch?v=ceCo8U0XHqw} See also: [FlutterView], which provides some additional detail about this property and how it relates to [padding] and [viewPadding]." />
     </histories>
     <option name="languageScores">
       <map>
-        <entry key="CHINESE" value="486" />
-        <entry key="ENGLISH" value="487" />
+        <entry key="CHINESE" value="492" />
+        <entry key="ENGLISH" value="493" />
         <entry key="HAWAIIAN" value="1" />
         <entry key="POLISH" value="1" />
         <entry key="ROMANIAN" value="1" />